Security Culture Hacking with Rapid7 Cloud Risk Complete and Tagging Strategies

Last week I wrote about the whys and hows of MTTR.?This week its Asset Tagging Strategies - why its important and the different "hows" of implementation.?Rapid7 Executive Risk View LETS GO!

OK so leading on from MTTR (Mean Time To Remediation), how can an effective tagging strategy help to reduce this MTTR??Im going to cover Accountability, Logical Application grouping and obviously Criticality of the asset, and then talk about how that helps us surface other underlying cultural issues.

There are many other uses for tagging however I want to focus on these three as they facilitate our culture hacking journey and long term goal of MTTR reduction.

CRITICALITY

So, step 1 is we start with a small group of assets, prove the theory and then expand.?Trying to tackle thousands of assets right away will likely prove to be a too bigger job.?This is why at the initial stage we should identify the criterias as to what defines a "business critical" asset.?These are the assets that would cause the greatest impact to the business if they were offline.?This is our initial scope, and the tag that should be applied will be something on the lines of "Business Critical".?It may be that there are a few hundred assets / resources that fulfil this criteria.?This is fine, but try and be strict in your role out of this.?

I have listed criticality as a starting point for scoping here, however you may also want to think about other tags you would like to use in order to scope the assets you are starting with in your first iteration.

APPLICATION GROUPING

Next we can look at logical groupings of assets.?For example if there is an internal business application that comprises of a back end databases and web servers these should be tagged as a logical application.?Although there may be different teams involved with administering and keeping the components up to date, particually with monolithic applications there are often many interdependant parts.?This often means that some components cannot be upgraded or patched in isolation without impacting other elements of the solution.?

note - monolithic apps are often built as a single large interconnected unit.?itegrations are often tight, and long term they have issues with scalability, maintenance and single points of failure.?Cloud technologies such as containers and serverless functions aim to break this down into whats know as microservices architectures.??

In a previous role as a solution architect I would often find an upgrade of a solution that comprised of only 10 or so servers would sometimes result in nearly two weeks of professional services due to the contingency that needed to be built in for the upgrade - particularly if the customer was very operationally risk adverse.?This often meant that customers would not upgrade their solution for long periods of time due to cost (which in turn made the upgrade even riskier!... ironic right?!).??

Ensuring you are applying logical application tags across your environment will give you a true reflection of over all risk a single business application may be introducing into your environment, and enable you to better build the business case for re-designing away from a highly-coupled monolithic design to a microservices orientated design.

ASSET OWNERSHIP (ACCOUNTABILITY)

In his book "IT Security Metrics" Lance Hayden uses a case study by Doug Dexter on his time as team leader in cisco's corporate security team.?In this case study they state several lessons, one of which is?

"Knowing who owns a host is more valuble than knowing what vulnerabilities are on a host"

At this point they created a new set of metrics based on asset ownership and discovered from the evidence that the most dangerous hosts (most vulnerable) in their environment where hosts that were either unregistered or had owners who had either left the organisation or changed roles.??

"Vulnerable hosts with no owners were difficult, if not impossible to remediate.?We couldn't 'blackhole' them (disconnect them from the network), because we didnt know whether they were still providing mission-critical services.?They became our most urgent priority, and we began to sleuth out the owners."

The report above was completed in 2008/2009, but there are still many organisations who do not have a tagging strategy in place.??

Asset ownership and accountability is the linchpin that you need to begin driving improvements in your vulnerability management program and resulting MTTR, but its no good assigning an asset to someone who has no budget or influence to get it patched.?Here there must be an alignment with those who have budget and authority to get the asset remediated.?You will also need to account for any conflicting KPI's in this alignment strategy e.g. if the operational team are tasked with keeping the lights on at all cost and dont want to take the platform down for patching then there is a conflict of interest that must be resolved before you can start driving down the MTTR.??

BUILDING UP PATTERNS

InsightVM and Insight CloudSec both have the ability to apply multiple tags to assets, and have had the functionality for a long time.?If you have been making use of it already then thats great, if you are yet to implement it, well you know what they say... the next best time is now right!

You will be able to start crunching through your vulnerability data that will show trends that are specific to your organisation.?From this data you will discover new and interesting ideas about your organisation that you had not realised previously, and you will have lots and lots of questions... why why why!??

EXPLORING ORGANISATIONAL CULTURE

This will be your next frontier!?The results based on your tagging strategy will lead you to deeper questions about the organisation.?This is the point at which you will need to go off into the organisation and start to discover why these cultural nuances are in place.?You might discover that there is a disparate team managing a large application and that all teams are bogged down by existing processes or conflicting KPIs that both hinder the upgrade of the application and also hinder the progress of both teams and introduction of new features and business value.??

Lance Hayden explores security culture in his book "People Centric Security: Transforming Your Enterprise Security Culture".?The first chapter is called "Adventures in Culture Hacking".?Organisational Culture in Security is certainly an interesting place to explore as every organisation is different.?sure, some have similar issues, but there are still many nuances to be explored that are unique to that organisation.??

FROM CULTURE HACKING BACK TO MTTR

Exploring the cultural issues will help you expand on the diagram in the last article.?It will help you map out more areas of influence, more processes, how teams work together and other controls or dependancies you have missed.?The end result will be a threat model for your vulnerability management process.?You will be able to see where you can inject failure conditions to cause the vuln management and remediation process to fail.?This will also add improvements to your organisations resiliency from a process perspective.

HAPPY (TAGGING) CULTURE HACKING!

Security isn't just a technical problem.?The technical problems are often produced by cultural and socio-technical problems. Socio-Technical problems are interdependent parts of Complex Systems.? Rapid7 products can help you surface these issues and explore the data (through a robust tagging strategy) so that you can begin to ask the questions you need to.?

Remember, start with a small scope, prove the theory and iterate.

Happy Culture Hacking!!!