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.
No comments:
Post a Comment