Madness: Embracing Complexity

A core process to drive security assurance

We're at the point in this series where we've talked a lot about the fundamental theories behind my approach, that we can now start talking about the how - in other words, let's start talking about some workflows.

At the center of my approach is a core workflow that I usually call the security assurance workflow, or process. Many other processes will either take data out of this workflow, put data in, or be a sub-process to this assurance workflow. That is because this is the main way in which you gather quality information (the "accidents" and "substance" discussed in part 2) about your assets, and use them to improve your overall strategy. The key to this information gathering is using a quality GRC tool as your record keeper as throughout the workflow you will need to create, update and maintain records about assets and applications. You will also need to be able to make decisions based on the information in those records, and ideally be able to make measure trends across multiple applications. Is it possible with spreadsheets? Yes. Would I try it ? Only if I really, really, really had to.

Now down to business. There are 4 phases to this core workflow - Discovery, Triage, Assessment, and Management.

Phase 1 - Discovery

As it's name implies, Discovery is all about finding out what your assets and applications are, and making records of them. Depending on your organizational context, and rate of change, this creation of records can be a point in time exercise, or can be continuous. Most organisations I have operated in have had a pretty regular churn of new assets and applications, so I generally do discovery as recording of the assets I know about, and I usually create a discovery process that allows for the continuous creation of new records.

When you're doing discovery, the most important thing is to attribute ownership to the most amount of assets possible. The ultimate goal of this process is to understand what problems exist, and to get them treated by the people who can fix them. This only works when you have accountability for the assets and applications that you have. Those "asset owners" will end up being the people who let you know how important and asset is, how secure it currently is, and who will ultimately own, or direct any risks associated with an asset. In practice the ownership of the various parts of the chain is a little more complicated, but principally speaking if an asset is owned by no one, it is also maintained by no one and security becomes incredibly difficult.

Categorization

I should also mention that in your discovery process, you will probably want to categorize your assets into pre-defined types. There's a bit of a rabbit hole with this, but without going too far down it, I have found that it can save you a lot of frustration if you make a conscious decision about what types of assets (or applications) you'd like to submit to a holistic assurance process. This is because you may not want to create deep assurance process about things like endpoint software if you already have robust processes around vulnerability management.

The act of categorization can also help with down stream processes. For example, client-facing applications may automatically change the Triage process. It can also help with the assessment process, affecting the types of questions you ask, based on if it's your own, in house application, or a SaaS based application offered by a 3rd party.

Phase 2 - Triage

Once you have some knowledge about what assets & applications you have, you're going to have triage them. We do this for the same reason that hospitals do this at A&E - You have limited resources, and you need to prioritise the security of certain assets over others, because most of the time they are not all equal. The way you do this is by doing a Business Impact Assessment of your asset. Usually I do this in the form of a customized BIA form sent to the asset owner, however in some cases you may already know the answers and can self-assess assets without specific knowledge from an asset owner.

The BIA is basically there to tell you what's the worst thing that could happen if this asset was lost. The best way I have found to do this is to create 3 or 4 categories of business impact from low to high or critical. Then, create a map of conditions which would qualify an asset as high impact, and gradually work down to conditions which would be low impact. The conditions change on the context of your organisation but usually I look at a combination of

• Amount of clients directly affected
• Amount of internal people affected
• Value of the asset if lost completely lost (or unavailable for a set period of time like 1 week)

With the map of conditions, you should create a formula that looks like IF X condition = true, THEN impact = Y category. Usually with the conditions as the value, or amount of parties affected drops, so does the criticality. For example an asset that affects 100 customers might be critical, but an asset that doesn't affect any customers might be low criticality. You can make this as complex or simple as you like, however I would recommend starting with categorizing an asset as critical if any of the high impact conditions are true, rather than trying to over complicate things out the gate. This simple approach will often lead you to only considering assets as "low impact" when they genuinely don't impact much at all. The best way to test this is to do BIA's on a cross section of the assets where you feel you have a good "feeling" about their impact, if the impact is wrong, tweak your formula until it feels right.A

HOT TIP - Avoid doing this in isolation. The definitions of business impact should not be rooted in security. It is literally about impact to the organisation, not impact to security. This means that your categories, conditions and qualifiers must match the businesses perception of impact. Check with your senior and C-Suite stakeholders that this categorization makes sense to them. Ideally, I would go further and say that BIA definitions should be rooted in your businesses' appetite for risk - though not all organisations have the maturity to articulate this.

Phase 3 - Assessment

This is the birth of my systematic approach. Because this is the stuff I use to do manually, day in and day out, on any number of projects, assets, systems and applications. Classically, a security assessment is a time consuming process, where you try to gather all the information you can about an asset, and try to threat model it. However, what I came to realize is that I was always asking the same kinds of questions. Often that was because I always needed to know the same sorts of things in order to know if something is secure. Often a lot of those questions were redundant and down right stupid, because they didn't really apply to the project. After awhile I also realized that when certain conditions were met, there would always be some kind of risk. For example, a system directly exposed to the internet, which contains sensitive information, and for which incoming connections are unencrypted, will almost certainly be considered highly risky behaviour. So why was I wasting time deep diving to find the obvious problems?

This is when I created my particular security assessment methodology. Most of the time, when you're asked to assess something you don't really know what an application does, or how it's setup. You need to find that out from the people who built the application, who use it, and who maintain it. So you ask them, the asset owners to give you that information through a security assessment form. The secret is to make this form both standardized, and flexible so that it can apply ot the widest range of assets and applications. This form & process then gives you 2 things:

• A standardized security posture of your asset (as dictated by any metrics you find important)
• A set of risks for where the posture is clearly insufficient

Remember that Risk Management is the key driver of change in this approach. However, there's an art to making this work for you. You've got to strike a balance between asking too many questions, and too little questions. You also have to make sure you only ask questions which generate usable data & risks that you want to keep and persist in your records.

Balancing human lead assessments versus "Computer Says No"

Ideally, you would like to deeply assess all of your assets and applications. But let's be realistic here - that will never happen. This is where the triage bit comes in. As much as possible, try to get automated assessments for all applications (even this is quite difficult as you will always have a few assets that evade ownership). Treat this as the first step in your assessment process, maybe your bare minimum.

The automated assessment approach is there to help your expensive security experts and to give them a baseline of information with which to work with. However you must be careful to not spend your valuable human capital manually reviewing and assessing all applications in depth. It won't deliver value to you, or your business. Save that energy for the business critical assets. Those are the ones that you want to have an expert review in detail, ask much more targeted follow up questions, and go through a more formal threat modelling exercise. Those are the ones you want to have a high degree of certainty about, and those are what your stakeholders will care to know about.

Be comfortable with having less certainty about lower priority assets. Trust me, if you're following this process, you're already creating a much more detailed picture than most businesses I and my network of peers have seen. Also, remember that even if you have less certainty, you would have

Phase 4 - Management

Finally, we're at the management stage. I could have called this the Risk Management stage, because here that's the primary activity. The assessment phase generally provides you with a point-in-time security picture of an asset, as well as set of qualified risk. Those risks are the "action items" that you assign to asset owners to mitigate. With a reasonably robust risk management process, you will have a process where by you can identify and fix risks for your assets.

While Risk Management is the primary activity, there is other cyclical activity which should happen here, which is re-certification. As I mentioned before, the assessment is a point-in-time exercise, and at any given point gives you a snapshot. But assets and applications are dynamic. New features can be released, and you want to ensure that you're tracking those changes at a medium to high level. This means that on some regular basis (for example yearly), you go back to re-assess the security of an application and discover if there are any new risks. It stands to reason that if risks are mitigated between your initial assessment and you're re-assessment, you should update the records for the asset so as to not re-discover invalid risks.

This management phase is also key to the "Art of Not Caring." Once you've come to this stage, you've essentially done the job of informing the business about their risks, who owns them, and what they can do about them.

Creating an automated framework

Essentially, this process is about establishing a framework where you maximise your time investment in qualified information, an minimise your time investment investigating unqualified information. You're doing this by automating most of your tasks in the security assurance process, and offloading the information & data entry to asset owners. I have definitely worked in organisations where people didn't initially love this, and that was often because they didn't have the answers to my questions. In turen, those same application & business owners generally understood the value of those questions and that if they didn't have the answers, there's no way you (the security function) would have the answers. So even in the most "resistant" environment, the need for accountability was obvious. As someone implementing this, you need to capitalise on this. Remember, security is a singular function in the business. You can't solve all it's problems.

What's Next

The can of worms is fully open, and there's still a lot I want to explore within this series. Stay tuned for tips on what I believe a good "asset centric" GRC architecture looks like, what I think are good templates and rules for assessments, as well as what I believe a risk management process should look like.