In the company where I work there’s a team in charge of writing the PLC programs.
Since this program is “part of the machine” and might evolve risks, I think those programs should also be included in the risk evaluation.
The problem is since the persons involved on the risk evaluation are not experts on STEP-7/AWL this part of the machine is not evaluated.
I’m thinking on somehow documenting the software and realize the risk evaluation based on that documentation. How that could be done? Is there a standard we can follow? The true is I’ve never seen a documentation on a PLC program.
I think your problem is two fold and I will address both parts subsequently.
The first problem is how PLC programmers and the security analyst/risk-assessor should interact.
The second problem is how to define a document - and I will brainstorm a possible sample rough outline and what it should include.
I think there are processes for these 2 to communicate. E.g. I have worked in places where security analysts writing documentation had to do weekly meetings with developers/architects in order to understand a system's architecture better and then to evaluate, assses, record, and document risks inside official documents.
No man is an island, and I don't think it's possible for 2 separate groups to come up with a reliable security assessment document without a few rounds/meetings and workshops in which information is exchanged.
Below I outline some steps you could follow.
A. Do an initial Meeting and Planning
The objective would be to set scope and goals.
Participants: Developers, security analysts, project managers.
Agenda:
B. Documentation and Information Gathering
As described in the comments, ladder logic (and the diagrams) are useful.
I do think however that you need to come up with a standardized structure/document within your company.
You also need to take into account additional things, such as networking between different PLCs and other servers/systems in additional to communication over protocols such as SCADA or ethernet.
Just check the well known security incident involving STUXNET. (Also mentioned below).
Possible template
Below is a rough outline for such a document.
Scope First off, you gotta define the scope of your project. This means laying out what your PLCs do, the requirements, specs, and other considerations of your solutions. Add assumptions, constraints, risks, and dependencies that affect your PLCs.
Hopefully, you use a Standard Format for your PLC code Next, I hope you use a standard format for your PLC code, like IEC 61131-3. If you don't, it would be nice to convert your code to such a standard and switch. This makes sure your code is consistent and readable, and works with different PLC platforms and tools. Stick to the naming conventions, comments, and indentation rules recommended by the standards.
Document the Inputs and Outputs Make a list of all the inputs and outputs in your PLC program. This includes sensors, actuators, switches, interfaces? and displays. Create a table or diagram that shows the name, type, address, and function of each. Map physical devices to logical variables. Additionally, document interactions with external devices/machines and also interactions of different PLCs with each other.
Document networking interactions Create diagrams that show the different messages exchanged between different PLCs (and machines) in your architecture. You could even use standard diagrams such as UML for this part. This will help map the whole architecture and will help a security analyst (risk assesser) foresee how attackers could attack PLCs/Critical Infrastructure using a combination of malicious code executed through combination attacks involving different OSs, languages, and protocols (e.g. windows + ethernet + scada). PLC networking protocols include: Modbus, Ethernet/IP, Profibus, Profinet, and CANopen.
A good example I just remembered (highlighting the risks of PLCs) is the story of the attack/virus that targetted PLCs from windows was STUXNET. Stuxnet targeted machines running Microsoft Windows and networks, then hunted for Siemens Step7 software. It compromised Iranian PLCs, grabbed data on the industrial systems, and caused the centrifuges to spin too fast and tear themselves apart.
C. Do Tests (and Document them!) Include test cases, procedures, data, and outcomes. Use a test plan or report to record all this info.
D. Document the Maintenance and Support Record the maintenance and support details of your PLC program. Include: updates, revisions, backups, and troubleshooting steps.
E. Collaborative Workshops
Perform in depth discussions. Walkthroughs of diagrams and code. Q&A sessions. Also perform live demonstrations if possible.
F. Identification of Potential Risks Threat modeling (e.g., STRIDE). Use checklists and frameworks (e.g., IEC 62443). Review past incidents and vulnerabilities both from your own systems - but also from other companies and the internet (e.g. STUXNET).
G. Risk Analysis and Prioritization Possible methods include, qualitative and quantitative analysis, impact analysis, likelihood/probabilities.
H. Development of Mitigation Strategies Implement technical controls. Develop procedural controls. Conduct training sessions.
I. Continuous Monitoring and Improvement Implement monitoring tools. Conduct regular reviews. Establish a feedback loop.
So, as I said, the problem is two fold and the solution should be 2 fold.
First define your company policies for how security analysts and developers should interact (and how often) in order to exchange the necessary information. Define the types of meetings, the frequency, and the required information.
Secondly, define the type, structure, and formats of the documents. Do use checklists, and where possible standards (such as UML, Strike security framework, etc..).
Finally, do define your processes - for the maintenance part of the project. Every time you do changes, do document them. The risk analysis should be updated every time there are updates to your PLCs, architecture, or network.
I don't know what kind of infrastructure you have (or critical/hybrid infrastructure) which is why I mention all of these.
Goodluck!