CIS 608/301 – Week 7 Blog Post: Controlling Risk in the Federal Government?

A number of strategies exist for controlling risk including defense, transferal, mitigation, acceptance and termination (Whitman & Mattord, 2014). The first seeks to put in place safeguards to eliminate or reduce risk. Transferal seeks to shift risk outside of the organization, such as with outsourcing or insurance. Mitigation is the application of controls to reduce the impact to organization resources during an attack. Acceptance occurs when an organization chooses to leave a certain amount of risk in the system(s). This typically occurs for two reasons, risk cannot be eliminated fully under any reasonable circumstance and funds for are scarce. Termination seeks to remove systems from the organization, such as the Federal government did with Windows XP systems, or at least tried to do, after Microsoft support ended.

Another term that is often mentioned when addressing risk is defense-in-depth. This strategy is in line with the strategies listed above and seeks to ensure security mechanisms exist throughout the system architecture so that an attack is less likely to be successful. There are several areas in an organization that can be addressed. The National Institute of Standards and Technology lists 18 separate families of InfoSec controls that seek to address all areas of the information system architecture (National Institute of Standards and Technology, 2013). When implementing these controls, an organization will be able to address defense-in-depth within its systems.

An example of the benefits of these strategies can be seen in a typical attack taking place across an Internet connection. The first thing that must be available is an attack vector to a target system. The second is that the target system must generally have a vulnerability that can be exploited. Last, the attack needs a path for exfiltration of data or for any malware installed on the victim system to communicate back. The strategy of defense could prevent all three of these factors. A mitigation strategy would ensure backups are available for the data as well as rebuilding the victimized system. Transferal could also aid via insurance payments or offloading responsibility to a third party provider. Several families of the NIST controls would play into these protections including access control, audit and accountability, awareness and training, configuration management, incident response, system and services acquisition, system and communications protection, and system and information integrity.

How well these strategies and controls get implemented is another story. One has to consider funding as well as the vast size of the federal government including the diversity of its many branches and organizations. Included in this should be an understanding of the differences in a headquarters office at the Department of Homeland Security all the way to a very small remote office with limited staff. There is likely to be a wide range of capability differences between two such offices and organizations must be aware of this in planning InfoSec strategies. Mandating controls that a small site does not understand or have the capabilities to manage will not aid in securing systems, no matter how well the “training” family of controls is implemented.  Funding is also a serious concern. With the OPM data breach (see previous post), there was adequate warning of security issues and also a significant lapse in time before the breach was discovered and reported. This is likely to be at least partially attributable to a lack in funding in IT and security staff and resources. If intrusion detection systems are deployed, that certainly would meet one of the controls but it serves no purpose if there is not enough staff to actually monitor the systems. Likewise, when staff resources are stretched and then pressed between keeping a system up and running or patching vulnerabilities, typically the mission will win out and the vulnerabilities will remain. This does not absolve any organization of responsibility for breaches, but decision makers should be aware that a lack of investment in both IT and security has consequences and may in fact accelerate those consequences. 

Works Cited

National Institute of Standards and Technology. (2013, April). Security and Privacy Controls for Federal Information Systems and Organizations. Retrieved July 24, 2015, from nvlpubs.nist.gov: http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r4.pdf

Whitman, M. E., & Mattord, H. J. (2014). Management of Information Security. Stamford: Cengage Learning.

CIS 608/301 – Week 6 Blog Post: Risk Management Framework Step 1 – Categorize Information System

Per National Institute of Standards and Technology Special Publication 800-37 Revision 1, the first step in the Risk Management Framework (RMF) is to categorize the information system (NIST, 2010). The guide to categorizing information systems for non-national security systems is FIPS 199 (NIST, 2004) and the guide for national security systems is CNSS 1253 (CNSS, 2012). However, both documents reference the need to classify data types as a prerequisite to determining confidentiality, integrity and availability (CIA). This is part of categorizing an information system and is a direct input into determining the appropriate security controls in step 2.

The NIST guide that is used to determine information types is NIST 800-60 (Stine, Kissel, Barker, Fahlsing, & Gulick , 2008). This document, along with the appendix, aids organizations in understanding the types of data that have been determined, and the applicability of them to an organization. Additionally, the documents also identify basic level of protections required for confidentiality, integrity and availability. While most have probably not read these and other associated documents, they actually serve as the foundation of the RMF since they are part of step 1 and affect everything that follows.

            Of note in this process of categorizing systems based on data types is that classification of systems appears to take a secondary role, though the documents do mention them. This is an interesting take and somewhat resembles the approach of industry to a degree. Industry has moved towards service based delivery and quantifies its services and associated contracts in service level agreements, or SLAs. Government does not appear anywhere close to being able to qualify or quantify its services or to sign an SLA guaranteeing a standard level of service. However, forcing government agencies to go through the process of focusing on data types is a way of focusing on what the organization is providing to its customers. This is a step in the right direction for organizations to both understand their systems and functions from a service and service level perspective but also to understand the IT systems supporting those services in that same context. When an organization begins to understand the services it provides, it gains much more of an understanding of the systems that support that service. When that occurs, it is in a much better place to really understand the risk to its systems and services and better apply risk management.

Works Cited

CNSS. (2012, March 15). SECURITY CATEGORIZATION AND NATIONAL SECURITY SYSTEMS. Retrieved July 16, 2015, from http://www.sandia.gov/fso/PDF/flowdown/Final_CNSSI_1253.pdf

NIST. (2004, February). Standards for Security Categorization of Federal Information and Information Systems. Retrieved July 16, 2015, from csrc.nist.gov: http://csrc.nist.gov/publications/fips/fips199/FIPS-PUB-199-final.pdf

NIST. (2010, February). Guide for Applying the Risk. Retrieved July 16, 2015, from /nvlpubs.nist.gov: http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-37r1.pdf

Stine, K., Kissel, K., Barker, W. C., Fahlsing, J., & Gulick , J. (2008, August). Guide for Mapping Types of Information and Information Systems to Security Categories (Voumel I). Retrieved July 16, 2015, from csrc.nist.gov: http://csrc.nist.gov/publications/nistpubs/800-60-rev1/SP800-60_Vol1-Rev1.pdf

CIS 608/301 – Week 5 Blog Post: New Federal Government Overreach?

Sometimes it is difficult to determine if the federal government is genuinely interested in assisting the private sector in solving problems or is simply interested in assuming additional authority over the private sector. In the case of cybersecurity, it appears that the government is united in its support of strengthening security against criminal hackers and especially state-sponsored hackers. The point does not belong to either party but is the domain of both major parties. According to one article, a poll among defense leaders across the military, national security policy, defense industry and congressional staffs found that the top security threat to the United States was cybersecurity, including among both Democrats and Republicans (Herb, 2014). Americans understand that cybersecurity is now a critical aspect of national security. The problem is that much of our national critical infrastructure is tied to the Internet and exists outside of direct government oversight, though the government does maintain some oversight of certain industries via regulations.

            On February 12, 2014, the federal government under the National Institute of Standards and Technology released the Framework for Improving Critical Cybersecurity Infrastructure. The development of this framework was driven by Presidential Executive Order 13636 “Improving Critical Infrastructure Cybersecurity”, directing an enhanced security and resilience of the Nation’s critical infrastructure and to maintain an improved cybersecurity environment (National Institute of Standards and Technology, 2014). The development was based on collaboration between the federal government and private industry in the hope that it would encompass private sector concerns and be more easily adoptable by organizations in industry. The framework can mostly be displayed in a spreadsheet. The spreadsheet would consist of a column of five core functions which are then subdivided into categories (similar to NIST 800-53 security controls) and sub categories, which are similar to NIST 800-53 sub controls. The spreadsheet also contains a limited mapping to other security models and is intended to be a best practices model that can be easily adopted by industry. There are a few other components of the framework including the Framework Implementation Tiers that primarily are concerned with allowing for an organization to be rated (or to rate itself) against four categories from Partial (Tier 1) to the most advanced Adaptive (Tier 4) tier. The final component is the Framework Profile where organizations develop a profile based on their industry, business and information security needs in light of what the Framework provides.

            Adoption of the new framework has been ongoing since its creation, though it has yet to be widely adopted. One article noted that some critical infrastructure companies in banking have begun proactively adopting the framework (Raysman & Morris, 2014). Of note is that the banking industry is already highly regulated when it comes to cybersecurity in regards to the Graham Leach Bliley Act (GLBA) among others, meaning that such an organization is likely voluntarily incurring additional costs for implementing and tracking compliance with this voluntary framework on top of other regulations that are currently mandatory.  Another article noted that security mainstay Symantec Corporation has already proactively adopted the framework into its security practices (Jackson, 2014). The article goes on to note that some see it as a semi-coercive attempt to begin regulating cybersecurity in industry and that it is not widely adopted at this point. One could hardly be critical of industry concerns, though it was developed with industry participation, with governmental reach into industry with the widely panned overreach of the NSA based on a flawed interpretation of the Patriot Act among other revelations of NSA and governmental activities. Still, some companies have proactively begun adopting the framework, whether for liability purposes as noted in (Jackson, 2014) or genuine concern over cybersecurity is not known. It is expected that adoption will be uneven in industry as the bottom line along with estimates of any resultant liability for non-compliance with a voluntary framework, will drive most industry decisions on adoption or non-adoption of the framework.

           

            The Framework for improving Critical Cybersecurity Infrastructure is currently on version 1.0 and it is understood that updates will be coming (Jackson, 2014). How long will it be until some critical infrastructure is hacked and the resultant uproar points to the inevitable new laws to bring order to the chaos? In our highly connected country with the 24 hour news cycle, outrage is spread quickly across the country at various events, most recently the murders in Atlanta and following actions brought on by the resultant pressure. This is not to say that this model of interaction is either good or bad, but to acknowledge that it is simply the way our society works in the present. What it portends is a reaction across the US among citizens, government officials and elected officials that would be predisposed towards a national response, which would then necessitate a governmental takeover of responsibility or strict oversight of cybersecurity for all critical infrastructures. With the existing Framework for Improving Critical Cybersecurity Infrastructure already in place and partially adopted by industry, the only logical step would be a new law mandating its implementation across all associated industry.

Works Cited

Herb, J. (2014, January 6). Poll: Cybersecurity Top National Security Threat. Retrieved July 10, 2015, from thehill.com: http://thehill.com/policy/defense/194475-poll-cybersecurity-top-national-security-threat

Jackson, W. (2014, April 21). Protecting Critical Infrastructure: A New Approach. Retrieved July 10, 2015, from informationweek.com: http://www.informationweek.com/government/cybersecurity/protecting-critical-infrastructure-a-new-approach/d/d-id/1204577

National Institute of Standards and Technology. (2014, February 12). Framework for Improving Critical Infrastructure Cybersecurity. Retrieved July 10, 2015, from nist.gov: http://www.nist.gov/cyberframework/upload/cybersecurity-framework-021214.pdf

Raysman, R., & Morris, F. (2014, December 18). CIOs Ignore the NIST Cybersecurity Framework at Their Own Peril. Retrieved July 10, 2015, from blogs.wsj.com: http://blogs.wsj.com/cio/2014/12/18/cios-ignore-the-nist-cybersecurity-framework-at-their-own-peril/

CIS 608/301 – Week 4 Blog Post: Configuration Management

Configuration management is identified as one of the security controls within NIST 800-53 document (National Institute of Standards and Technology, 2015). This is not to be confused with security configuration management or SCM as it is known. SCM is concerned with security configurations on a system such as the Security Technical Installation Guides available for Department of Defense systems. Configuration management is based on defining a baseline of hardware and software installed on a system and the policies and procedures that control and enforce that baseline.

Beyond information security, configuration management is one of the foundations of developing an effective information technology program within an enterprise. While it is defined as a security control, it is also defined in other processes such as the Information Technology Infrastructure Library, or ITIL (HP, 2007). Understanding the hardware and software within an organization feeds directly into understanding the environment and populating a configuration management database (CMDB). While configuration management is primarily concerned with understanding what is deployed on the network at any given time, other processes such as change management are charged with tracking those changes and ensuring that the CMDB is updated accordingly.

            Unfortunately, configuration management is not very easy, typically growing in complexity, difficulty and labor requirements as the enterprise grows in size. While it seems straight forward, keeping track of what is deployed can be very difficult. Factors such as mission requirements, emergency changes, complex environment with multiple operating systems and other systems, lack of training and others can each undermine configuration management. Also, being forced to go through tedious processes can seem cumbersome and a waste of time to personnel who simply want to keep their systems running, meaning that it is also a cultural problem. Given limited funding in a less than stellar economy means that staff are likely burdened with responsibilities, most of which their job depend on and thus will always receive priority over something as extraneous as CM.

            While there are many issues with implementing CM, it does not negate the necessity of getting it right. IT services depend on accurate CM, especially if an organization has service level agreements (SLAs) to meet. Failure to ensure all systems are updated (easier if CM is accurate, can result in broken systems if corrective fixes cannot be applied where and when needed with accuracy. Such issues in managing the IT infrastructure are what lead to security issues where like systems are constantly in different software versions and configurations, thus leading to vulnerabilities on the network that can be exploited months or even years after patches are released. Making a commitment to CM can go a long way towards shoring up many of these issues but will likely only occur when management sees a direct correlation between CM and the bottom line and is thus likely to be uneven across organizations.

Works Cited

HP. (2007). ITIL v3 Configuration Management System. Retrieved 7 2, 2015, from hp.com: http://www.hp.com/hpinfo/newsroom/press_kits/2009/lasvegasevents2009/ITILv3CMS.pdf

National Institute of Standards and Technology. (2013, 7). NIST.org. Retrieved 6 26, 2015, from Biometric Specifications for Personal Identity Verification: http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-76-2.pdf