State Thinking

Thinking in states to handle information security complexities

Author

Sam Benjamin Pragasam
June 09, 2024

It is a paradigm to view the problems and outline/envision them as a state. A state is the temporary status of objects at that instant of time. The State can transition to other states through events called State transition. State transitions can be continuous or discrete. Continuous are time-based states whereas discrete are event-based and not dependent on time. One example of Continuous Systems is temperature monitoring where you observe temperature over periodic time. An example of Discrete Event System is Queuing System. Information security and many business functions fall under discrete event systems. This is a subscriber only post. I have discussed the below points in this post.

  1. Discrete Event Systems

  2. Security States

  3. Control mechanisms

  4. Multi State events

  5. Stage vs State

  6. Continuous Improvement

  7. Why Maturity Model fail?

  8. Identifying futile efforts

  9. Scope

Discrete Event Systems

For an example, You are working at an IT company and you got a good hike. you are in a happy state cause you are happy that you got a good hike and you wanted to buy a good watch. After a day, you get an unmet expense such that you cannot buy the watch you desired for. At that moment, you are in a sad state. Below is the diagram representing the states

The event e1 could be a single event or function of events that make a transition from happy state to a sad state . e2 are a function of events that make sad to happy state.

This could make you think of the lines of defences to put forth in order to not end up in a sad state i.e you put control mechanisms to manage/eliminate the events e1 that cause the state transition of Happy → Sad. One of the ways to manage is that you set expectations that whatever it comes you will take it as normal. Now a new state called normal state is being added to state space ( a collection/possibilities of all states in a system). We can call the Normal state an optimised happy state because the Happy state is the trivial (or) ideal state that all of us want to be but cannot be achieved at all times. That’s why we introduce a normal state where I am okay to be in that state called normal which is calm and composed and I want to be in that state for a longer period of time and it’s possible to achieve it rather than the happy state.

Security States

Mostly in information security, you can define two states, secure and insecure state. All the security programs/projects start from an insecure state and efforts are invested to move to a secure state.

If we take the vulnerability management process, the insecure state can have no visibility of vulnerability management (or) A new feature is coming for testing. We find bugs that give visibility and validation on which state the security program is currently in. The question is How will we move to a secure state? The answer is all found vulnerabilities are to be fixed. In the above diagram, the SE1 event transition in this context will be finding and fixing all vulnerabilities. Let’s say some vulnerabilities are not fixed. Does that mean that we have not achieved a secure state? The definition of a Secure state plays a critical role here. A Secure state is achieved when we have clean vulnerabilities, all vulnerabilities are fixed. This is an ideal and trivial state which is impossible to achieve because of complexities prevailing in the prioritisation of work. So we include another state called the optimised state. An Optimised state is a state which is better than an insecure state and lesser than a secure state. For example, We define SLA, and assign severities for prioritising which vulnerabilities are fixed first and which are important. Maintaining SLA of vulnerability management is the optimised state.

I have marked the SE1 and SE2 transition in dotted lines to convey that reaching Secure State is difficult to achieve and the efforts to be invested are more following other prioritisation complexities already present. A Secure state is always an ending state and it can never be a starting state.

We consider and focus only on the insecure state and optimised state. There are other problems a security team can face which are less investment in the security budget, misalignment across stakeholders and operational difficulties. But there will be always a budget to do compliance audits and it’s a must to do to gain confidence from customers and auditors. so we have another state called the compliance state. The difference between the compliance state and the optimised state is that we just do what compliance wants even though we can invest to reach the optimised state.

Optimised state and compliance state can be combined in certain scenarios. In vulnerability management case, having SLA and a timeline committed to fixing for prioritising vulnerabilities are both suitable examples of compliance states which meets compliance standards and there is no improvement we make after that. it is either we have to fix all vulnerabilities and reach a secure state and there is no optimised state.

Control mechanisms

The benefits of thinking in state could help you in thinking that there are many events which can bring compliance/optimised state to an insecure state. We can think of how we can make sure those events should not happen or be managed or controlled.

In vulnerability management, you can introduce blocking gates in pull requests to make sure the vulnerabilities are fixed within SLA.

Multi State events

Some events cause state transition in many different security parts and different state spaces. An event of an external researcher reporting a DOS attack can affect states in How the attack was missed while testing? How was the infrastructure did not able to handle the load? How the bug bounty program is handled? Do we have one? This event affects the vulnerability management state space and the bug bounty state space.

Stage vs State

We tend to think of security measures as stages. A stage is when you achieve that state for a longer period. We would not say I am in the happy stage. But we can say I am in the adult stage of my life. In stage thinking, you cannot go back and it is a linear thinking model. Thinking in state helps us to think in non-linear mechanisms, and detect and manage failures.

Continuous Improvement

State thinking gives you a perspective that you can never be in any good state for a longer period. There will be some events which are in our control or not in our control that move the state to the previous bad states. This paves the way for continuous improvement, there will be failures, identifying those events which cause bad state transitions and to be fixed continuously.

Why Maturity Model fail?

Maturity models such as DevSecOps maturity model , BISIMM maturity model are stage-wise thinking. You follow their guidelines to achieve the model level. For example, OWASP DevSecOps maturity model are linear thinking model, you validate your current environment practices to their levels. If the security program passes level 1, we will work on how we can achieve level 2. What are the measures we have to take to stay at level 1 for a longer period of time? Would the level2 of the maturity model goes back to level1 by any chance? No security program following the maturity model would go back from level 2 to level 1 cause it is a linear model. The model only supports linear/stage-wise thinking. In the current complexities, even if you are attaining OWASP maturity model level 3, It does not mean that you are in a secure state. The maturity model gives you that you have achieved the mature state and it is “done”. There is no continuous improvement in the maturity model. On the other hand, the Capability Model does not have a done state, rather it is tied to outcomes and supports continuous improvement.

Identifying futile efforts

There are efforts you can invest in but that does not move the current state aka security theatres. State thinking can help in identifying looping efforts.

SE-1 is the event that causes state to be in the same state. We should detect those SE-1 efforts that cause those events. There are events which are not caused by us and can be caused externally, out of our control which I am not including.

Scope

Deciding scope is similar to deciding and implementing domain boundaries in microservices. More services leads to more operational efforts, performance issues. Similarly, more scope leads to handling more state space and state events. We have to achieve balance and accept the tradeoffs.

Conclusion

Thinking in states can open up new possibilities for managing and handling information security programs and their outcomes. I hope that this will give you an insight into thinking in state with an example.

These books can help you get more depth in state thinking

  1. Christos G. Cassandras, Stephane Lafortune - Introduction to discrete event systems-Springer (2007)

  2. Modeling Software with Finite State Machines_ A Practical Ferdinand Wagner, Ruedi Schmuki, Thomas Wagner, Peter (2006)

  3. Simulation Modeling and Analysis by Averill Law and W. David Kelton (2000)

Reply

or to participate.