Adam Montville,Security and Compliance Architect at Tripwire (www.tripwire.com) describes 20 critical IT security controls.
The Center for Strategic and International Studies (CSIS) in the United States recently released Version 4 of the Twenty Critical Security Controls as was determined by a consortium which included representatives from the NSA, US CERT, the DoD’s JTF-GNO and Cyber Crime Center, the DoE, the State Department, and some top commercial forensics experts and pen testers from the banking and critical infrastructure sectors.
The critical controls identified by the workgroup focus on four basic tenets:
– Offence Informs Defence: Using knowledge from actual attacks to build effective defenses
– Metrics: Establishing metrics standards to measure the effectiveness of security
– Continuous Monitoring: Continuous monitoring/auditing to validate whether security measures in a timely manner
– Automation: To achieve reliable, scalable, and continuous measurements of controls.
Implementing these controls will take you on an eye opening journey through your enterprise and its critical networks, and it will help you plan for improvements over time. Because the Controls are so expansive and highly detailed, I organized this series so you can refer back to this digest as a roadmap for identifying the primary actors, processes and tools involved.
The articles are intended to highlight the specific requirements you need to understand, and can later be used as a checklist. Links to a more expansive examination of each Control identified are also provided. Here are the key points for the first two Controls we will be examining:
Control 1: Inventory of Authorised and Unauthorised Devices
In a Nutshell:
•Don’t do it all at once: This Control involves the orchestration of several business processes and is proportional to the size of the organization
•Take these requirements to your vendors: If your tool vendors aren’t aware of these requirements, the data integration between business processes will be your burden
•Look for standard data formats to be supported in tools: The tools you have today and in the future should support standard data formats, in particular the Asset Identification specification
•Start Small And Basic: This Control is process heavy and will benefit from automation. Start by getting the discovery and inventory maintenance down pat and integrating that with the incident detection and response
Areas for Improvement:
•Use terminology consistently: The term “system” is a great example, as it can mean a tool or component or can encompass people, process, and technology
•Level of Abstraction. T this Control really assumes an IP-based network, but some of the more critical problem domains may not use IP-based networks exclusively and may have different requirements. It would be nice to see some level of abstraction to cover these fringe cases
•Explain Why: In a couple of instances recommendations are made without any real explanation as to why. Clarification would be helpful
•Dependencies: Throughout this Control there are allusions to processes that must exist for the implementation to be successful.
Control 2: Inventory of Authorised and Unauthorised Software
In a Nutshell:
•Don’t do it all at once: A repeat from Control one. Asset inventory is hard, and the software piece of that is no exception
•Start Small and Basic. Another repeat from Control one. There’s too much that can go wrong if you try to go big too soon. Understand that there are some obvious ‘edge’ cases that will need to eventually be covered
•Take Control 1 and Control 2 together: There are too many similarities between Control 1 and Control 2 to not treat them as ‘one Control.’ Why make the distinction from a process perspective? Computing devices and software are assets from a business perspective, so tracking both with a degree of accuracy is important
•Take these requirements to your vendors: This too is likely to be a trend. This Control is full of requirements you should bring to your vendors, especially those related to interoperability features and functionality
Areas for Improvement
•Combine Control one and Control two: It’s pretty easy to see that computing devices are the same as software if we look at the world from the perspective of what an “asset” is – they all have value to an organization. When we get to the tenth requirement, you’ll see what I mean
•Dependencies: There are many allusions to a menagerie of processes and procedures throughout this Control, so it makes some sense that having a succinct list of these dependencies would be helpful for interpreting control frameworks
•Rethink Today’s Organisational Needs: There are always exceptions, so there is no way a single Control framework can address everything for all types of organisations. I recognise this as a fact, and I think some of the requirements here are stuck somewhere in the last decade. For example, what organisation is going to subject a R&D organisation to a change management process for installing software? The majority of give developers admin rights because they need them to regularly install software on their systems, which presents a dilemma from a security perspective, but it’s the reality of the situation
In conclusion, I recommend that you consider treating physical/virtual and software assets the same and use a single Asset Management system to manage them. If your first thought was, “What Asset Management system!?” then you should spend a significant portion of your time planning to implement one and remember to start at the most basic level – computing device and operating system seems like a good start – and to iterate from there. Document your processes and procedures along the way and keep them up-to-date (you’ll thank me for this later, I promise you).
Tripwire is exhibiting at Infosecurity Europe 2013, the information security event in London on April 23 to 25, 2013 at Earl’s Court. For further information – visit www.infosec.co.uk.
