Why We Need Security Policies
April 30, 2019 at 8:00 AM
rs=w_1280 (2).jpeg

It's Just Results knows that the best solutions and ideas come from teams. We prefer working with collaborative and innovative partners in security and compliance. One of our partners is ThreatSwitch.  

This post was created in partnership with ThreatSwitch, a cloud-based industrial security compliance solution that aims to radically simplify and automate high volume, data-intensive, and administrative tasks. Please visit threatswitch.com to learn more. 

ThreatSwitch invited us to participate in their Partner Perspective series. The focus of the series is to share insights that you can use to improve your own security program and policies.

Why Policies

There is no greater despised document in business, past and present, as “the policy document”. Diligent business security and security management systems require effective and applied policies and without them your business is at greater risk of exposing you to a number of threat actors seeking to exploit security vulnerabilities.

In Aerospace and Defense (A&D), the leading driver for improved security has been the Defense Federal Acquisition Regulations (DFAR) clause 252.204-7012, a response to an ever-growing concern of the lack of A&D supply chain security. Policies make up many of the direct controls of the DFARS 252.204-7012 requirement to implement the controls specified in National Institute of Standards (NIST) Special Publication (SP) 800-171 designed for non-Federal organizations, including hardware, software, configuration, and policy/process.

Policy implementation is an expected safeguarding measure (Page 41 of the June 2017 DOD Industry Information Day provided input for figure 1 above), and security policies have a direct role in 37 of the 110 controls in the special publication.  Drafting policies for configuration, hardware, software security controls is a key component of aligning to the DFARS requirements.

It's clear that policies are the foundation of an effective security management program, but many organizations still struggle with ineffective or nonexistent policy development, implementation, and sustainability practices.  Here's a look at a real-world example we compiled from multiple clients who each sought to create a culture of security in response to threats. For the purposes of this case study, we'll attribute this journey to a singular person who we'll call "Caroline," but keep in mind that this challenge may be familiar to many industrial security professionals, possibly even you. 

The Challenge

Caroline is the Chief Operating Officer of a consultancy doing work with both federal and private sectors and functions as the company’s Facility Security Officer (FSO). Her company also handles Controlled Unclassified Information (CUI).

In 2018, a phishing incident occurred that required Caroline to mitigate the root cause and identify:

  • The fraud perpetrator (threat actor)
  • The origination point
  • The threat vector/process
  • Business Impact

When Caroline briefed the staff, it was clear that the company was not fully prepared to handle incidents and had not decided how to identify, contain, eradicate and recover from these events. A follow-up on IT security protections revealed that there was not a clear process for the company to deploy security, improve security, or to train the entire staff on security actions.

The Solution

In order to solve this specific incident, and use this event as a catalyst to instill a culture of security, Caroline focused on establishing security strategy and activities that aligned with her company's culture and budget.

A security assessment helped uncover what security would need to look like given the business objectives, business culture, and technology stack used by the company. The assessment tested several hundred security controls (don’t be put off by that number, security requires detailed decision making) to understand the current state of security and the security decisions that needed to be made. Current security practices and new security activities were identified and combined to produce an overall security mosaic in the business prioritized by activity. Each activity in the business’ security mosaic required a decision (what will be done, how much will it cost, does it fit the budget) with the emphasis placed on higher priority activities. Once the decisions were made, they were codified. The codification took place in the form of policies.

Caroline also established a governance process to manage security, track implementations, and create security training materials to improve staff awareness.

The Results

The newly created policies identified precise administrative and technical activities. Furthermore, the company could now track policies because they had defined actions, responsible roles, and frequency of performance identified. This process let Caroline oversee the improvements and create agendas to discuss in the quarterly governance process recommended in the roadmap.

After the first quarterly governance meeting, Caroline felt she could see what was being accomplished and the improvement in the company’s security posture. She could also see obstacles that the implementation team was facing, and she had established a list of training lessons to have the greatest impact on the staff’s semi-annual training. The company was improving IT security and changing its staff’s competency regarding security.

Is any part of Caroline’s journey familiar to you? What are your own experiences?