The “C” word that will save you some trouble: Categorization

A few years ago I was trying to think of an approach to ensuring data that was classified was protected appropriately.  I had a few problems – I knew that the approach I came up with needed to be flexible.  I’ve tried assigning data owners and it is akin to pulling teeth. It has been my experience that corporate cultures do not want or support security liaisons or managers as additional duties.  I conducted some research and did some digging.  This blog entry is the result of that digging. I developed a system centric approach to increased information confidentiality, tighter regulatory compliance, smarter application of security controls (cuts costs too), shorter/better recovery times and improved information management.  The process begins with the system development lifecycle. 

System Categorization and the SDLC

In your IT project lifecycle there should be security integration.  If you are looking for a guidance on security integration in the SDLC, NIST is a great start.  Be ready to edit the NIST document as it is not a “one size fits all” approach.  It is important to know when a step in a process is too “heavy” for your corporate culture also.  Whatever the level of involvement of security in the Project Management Office (PMO) process (mileage may very per PMO process), there should be a step in there where IT Security understands the classification of the information being stored or processed by the system being implemented and security requirements are developed to be integrated into the system – as early as possible.  I’ve seen classification criteria vary from company to company, DoD’s classifications are Top Secret, Secret and Confidential. The private sector classification criteria may look something like Confidential, Private, Sensitive and Public.  The categorization process will not work without a data classification policy and documented criteria.   I’ll use the private sector classifications listed above in my examples.  In addition to data classification and protection, you also need to consider system criticality.  If there is a system failure many companies have a threshold documented and availability criteria documented.  My assumption is you have both of these required criterion that outline classification and system availability.  I will use Very critical, Pretty critical, Low criticality and No criticality.

Figure 1: Example of System Categorization

The example in Figure 1 is how some common systems may fall out in the matrix.  Figure 2 shows the actual categories under each of the criteria.

Figure 2: System Categorization Matrix

Where the rubber meets the road

Next you will want to show where security requirements relate to the matrix.  WARNING: This can get very complex very fast.  Pace yourself – the hard part will be getting teams to agree to the ratings.  The REALLY REALLY hard part is when you try to get people to pay for requirements associated with the matrix.  It is very important to get alignment from IT leadership on the technical security requirements.  Try not to lock yourself into a specific brand technology (technology changes).  I recommend starting with a simple table like Figure 3 (this is an example and not to be considered a complete list of requirements).  Some might export all the requirements from the corporate security standards while others might refer to the monster list that NIST created and called the “Security Control Catalog”. Whatever control catalog you use, when aligned with a categorization methodology, it will greatly assist in applying the correct security investment and controls to your systems.  Also, by building these steps into your SDLC you will ensure the project teams fund for the controls that apply according to your approach.

Figure 3: Control Requirements

I hope this helps you if you have been faced with trying to ensure controls are applied at the right level for the right asset at the right time.  Next blog entry I’ll post something about security in the SDLC.

Enterprise Security Architecture: As Basic an approach as it gets

I wanted to share some work that I'm particularly proud of.  I was struggling with how I should go about documenting a security architecture in a way that any business leader could look at it and understand it.  If leadership don't get it - it ain't goin' nowhere! 

I had the traditional form of documented security architecture consisting of security processes, diagrams with firewall placement, roadmaps, hype charts, etc.  What I needed was something that someone could consume in one sitting and take away the priority and impact of a proposed strategic approach to security architecture.  I looked at several methodologies (TOGAF, SABSA, etc.) and they were shaping up to be months of effort.  These methodologies have their place and I'm not saying that the outcome wouldn't be worth the effort but in a time when we are asked to do more with less - I simply did not have the time to invest.   If you do choose to adopt a methodology like SABSA, this approach can be built upon to reach the same outcome.  Figure 1 below illustrates the process.

Figure 1: Rapid Security Architecture Development 

The process described:  Back to basics  
1) Brainstorm Security Services - I built a database of all the security services that any security organization could offer.  I brainstormed and documented over 65 core services ranging from Authentication to Vulnerability Assessments.  The Security Services database should continue to grow as the security program changes to meet new challenges.

2) Align Services with Technology - I chose to include this step to show alignment with our Enterprise Architecture team and to show services that were enhanced or covered by technology today.

3) Align Services with Defensive Strategies - Group the services into groups called Defensive Strategies. The defensive strategies should also align with the business and IT strategy if you ever expect to get any projects accomplished.

4) Organization assessment against listed security services - Assess each security service to determine what the status is.  Assign YES for security service is working; Assign PARTIAL for partial coverage and; Assign NO for not offered.

5) Align threats and gaps with the corporate enterprise risks - This is a multi-step process:
a) Develop a threat taxonomy - brainstorm all the threats that could have an impact on your particular business.  You can choose general threats like Abuse of Authority, Disgruntled Employees and Environmental Disaster.  Group the threats by Internal Malicious, External Malicious, Internal Non-malicious and External Non-malicious (this helps one understand threat vectors). 
b) It is a good idea to show risky business practice ratings, risk drivers/security motivators and show the Net Impact and Net Likelihood of the threats (Fig 2).  This gets the attention of leaders who understand threats and risks in business terms and places a kind of dashboard all on one slide.

Figure 2: Security Risk Context Example

6. Document the impact or priority of the security services - assign a HIGH, MEDIUM and LOW impact to each service to indicate the security services that are important to your organization.

7. Document the gaps in current services - By just adding up the number of services with yes, no and partial then looking at the impact rating, it is easy to see where time money and effort should be spent.

8. Align gaps with the corporate threat taxonomy - As you develop the threat taxonomy and align the threat with the risk this process helps you think of mitigation for the risks.  Simply align the risk with a security service.

9. Report findings - The alignment of gaps from step 8 will show you the services that you need to address the risks.   Figure 3 shows an example of how I might report the MFA security service, relevant threats and risk before and after the mitigation is applied and figure 4 shows another method of reporting the security services and before and after mitigation.  The risk level can be determined using the National Vulnerability Database by going through the weighted questions for each risk then going through them again and applying the security service.  This process may surprise you.

Figure 3: Example Security Service MFA

Figure 4: Another View of Security Services and Risk Ratings

10. Create a business aligned security roadmap - The roadmap will be all the security services that are developed as a result of your work.  Estimate external cost and time to implement for each security service as shown in Figure 3 in the lower right hand corner, this will help business leaders understand the level of effort and cost.

Whether you use this approach or another (or a combination) the result of an effort like this should benefit any security program.  I hope this helps readers strengthen their program or will expand your thinking.  If you find this useful, please just let me know - I like the endorphin rush when someone gains from my research, thought and hard work.