Republicii Street, No. 9, TM, Romania +40-256-201279
Tech

The vulnerability of Industrial Control Systems (ICS) systems is a major concern both for their beneficiaries, as well as for all those involved in the development of such software solutions. While software engineers (in and beyond ICS), know that a solid software architecture and reliable coding are the only way to go to reduce cyber risks, the users sometimes neglect the best practices in the daily use of software solutions.  When steering away from code that ends up being vulnerable, or easy to control via data breaches, as well as from its faulty deployment or configuration, the ICS-based recommendation can do no harm. They are also useful when considering other types of software solutions.

We browsed a few recommended methods for developing strong and reliable ICS software solutions, on the users’ side.

The ICS system environment induces an urgent need to solve or avoid vulnerabilities. This urgency drives best practices in this line of work. By extension, any solution with implications or application in the IoT field can be approached in the same way, even if the effects of its potential vulnerabilities are sometimes more difficult to grasp. But any element in an interconnected system is essential because the system is as protected as its weakest element is.

 

A seven steps list to avoid cyber risks, from Automation World

The list comes from a supplier of industrial cybersecurity software and services. It’s meant to provide a solid grounding for all the types of professionals who are involved in building and delivering safe and secure ICS software solutions.

 

As the author mentions, the list summarizes the “core steps every industrial company should take to secure their control systems at the most basic level”

Design your network with cyber security in mind

  • The software solutions beneficiaries/users should secure their networks to avoid exposure

Monitor your deployed software

  • Make sure you notice events and any abnormal behavior before it’s too late

Keep a tight inventory of all devices connected to your network

  • “From controllers to human-machine interfaces (HMIs) to engineering workstations, all assets on your network should be accurately inventoried so there aren’t any unknown devices, thereby enabling rogue assets to be quickly identified”.

Manage your logs, to understand the behavior of all involved devices

  • You can optimize performance once you have the complete image

Manage the configurations of all involved devices

Use industrial firewalls

Institute privilege control

 

As a user of software solutions, do these recommendations sound familiar?

Avoiding cyber risks is a common effort. Good software engineers strive to build and deliver the best, most secure products. Vigilant users should join in by materializing best practices, such as those mentioned above.

0

Tech

Code reviews are part of any software development environment. Not the most pleasant part, in what a developer is concerned, since it involves his/her work being scrutinized and it may feel stressful, “but it’s also one of the best ways to get feedback on your code, to catch typos and mistakes, and, more broadly, to grow as an engineer”.

In order to take some unnecessary pressure out of this process, there are tips & tricks synthesized in the online media that help both code developers and code reviewers make the best out of this stage. We asked a few collegues here at LASTING Software to help us select a few best practices/rules/recommendations.

Let’s review some of them, starting with the most quantifiable ones.

 

5 practical rules for code review

 

A developer should review less than 400 lines of code at once;

Keep the inspection rate at a density of less than 500 LOC per hour;

Try not to surpass 60 minutes at once without taking a break, if you want to keep a high performance;

Establish tangible, measurable goals for the entire process;

Use code review procedures that can be followed and tracked (checklists, collaborative tools, fixing processes to be implemented).

(Selected from Best Practices for Code Review, as presented by SmartBear)

 

5 recommendations for developers

 

Prepare a quick summary where you explain the problem and the proposed resolution;

Auto-review, prior to someone else reviewing your code, so you can trim some of the problems yourself;

Communicate – by using annotations to highlight all the soft spots, and tag the right people involved in the project that might clarify these problems you feel you need a second opinion about;

When the reviews are back, remember the importance of team work and concern yourself with their utility and processing prior (and over) feeling anxious;

Refactor changes without altering behavior.

 

5 recommendations for code reviewers

Always keep in mind the code purpose and the project scope;

Ask clear questions whenever the functions and classes reason does not reveal itself;

Be clear when highlighting the problem you have identified, and propose alternative solutions;

Write the reviews in a neutral and concise manner and avoid absolute judgments;

Don’t forget to mention the good things you notice – keeping it clear you review with the overall quality in mind, not just to hunt the errors.


You may find more useful advice, examples, and technical guidelines related to code reviewing in our third source of inspiration for this article – on Medium.

 

0