Every organization needs an effective cyber security policy

Anyone who has taken the CISSP exam knows that cyber security policy is at the top of the policy/standard/procedure hierarchy. The logic is that cyber security policy must come first because it identifies the organization’s security issues and their scope; it answers the question, “Why do we need to do this?” Only after understanding the why can an organization develop quantifiable measurements and determine what is required (standards), then establish the proper steps to achieve the standards (procedure).

Cyber security policy protects information within an enterprise, defines rules regarding consistency and fairness, and ensures compliance. Yet despite the high importance of cyber security policy, many small and medium sized businesses (SMBs) lack effective security policies. Some don’t have them at all! This “ad hoc” approach to enterprise cyber security has become such a problem among defense subcontractors that the DoD is developing a new compliance framework to address it.

Regardless of size or industry, every organization must have documented IT security policies to protect their digital assets. Many compliance frameworks, including HIPAA, PCI DSS, and SOC attestations, require written policies, and policy documentation will also help your company defend itself defend itself against fines and civil litigation in the event of a data breach.

Types of IT security policies

The CISSP defines three primary types of cyber security policies.

• Regulatory policies ensure that an organization is adhering to industry-specific compliance mandates or laws, such as those governing public utilities, financial institutions, or other organizations operating in the public interest.
• Advisory policies specify which employee behaviors an organization considers acceptable and unacceptable. While advisory policies aren’t mandatory per se, employees who violate them face serious consequences, ranging from serious warnings to termination.
• Informative policies educate an organization’s employees or business partners without laying out any specific or implied requirements.

These three IT security policy categories can be broken down further into organizational, system-specific, and issue-specific policies. An organizational (or master) security policy is the blueprint for an enterprise cyber security program; it outlines the company’s strategic plan for implementing cyber security. System-specific policies dictate the approved software, hardware, and hardening methods for specific systems. Issue-specific policies address functional areas that require additional attention and detail, such as IT security policies governing email usage, change management, access control, data retention, and vulnerability management.

Developing & maintaining an effective cyber security policy

Depending on an organization’s size, industry, risk profile, and data environment, their IT security policy could range from a one-page guide to a book containing dozens of pages. Here are some general tips for developing an appropriate and effective cyber security policy.

• Understand your compliance requirements and align your policies with them. If you don’t know where to start, applicable compliance mandates are a good place.
• Understand your infrastructure. Work with your IT team to map the systems you have in place, their capabilities and vulnerabilities, and your current backup and security measures.
• Clearly identify security controls. This includes which specific security programs are to be implemented, timelines and procedures for updates and patches, and backup procedures.
• Clearly identify employees’ roles and responsibilities. An effective IT security policy must define accountability, such as who is responsible for maintaining and enforcing policy, who is responsible for training users, and who responds to security incidents and each person’s role during response.
• Outline acceptable use conditions. This includes acceptable use of the company internet connection, social media usage policy, remote access rules, and the proper procedure for reporting security incidents.

Cyber security policy is not “one and done.” The cyber threat environment is in continuous flux, and security policies must be reviewed and updated on a regular basis.

The cyber security experts at Lazarus Alliance have deep knowledge of the cyber security field, are continually monitoring the latest information security threats, and are committed to protecting organizations of all sizes from security breaches. Our full-service risk assessment services and Continuum GRC RegTech software will help protect your organization from data breaches, ransomware attacks, and other cyber threats.

Lazarus Alliance is proactive cyber security®. Call 1-888-896-7580 to discuss your organization’s cyber security needs and find out how we can help your organization adhere to cyber security regulations, maintain compliance, and secure your systems.

Proposed Supplement to NIST 800-171 Addresses Advanced Persistent Threats Targeting Defense Contractors

U.S. defense contractors are being heavily targeted by foreign cybercriminals. An internal Navy cyber security audit ordered after a series of successful breaches of Navy contractors revealed an agency in complete cyber chaos “in ways few appreciate, fewer understand, and even fewer know what to do about.”

The majority of federal contractors are required to comply with the strict security controls outlined in NIST 800-171, and defense contractors have an additional requirement of complying with DFARS 800-171. However, the recent spate of advanced persistent threat (APT) attacks against defense contractors by nation-state actors prompted the DoD to reexamine its contractor cybersecurity requirements and ask NIST to develop a set of guidelines specifically addressing APTs. The result was NIST 800-171B, which was released in draft form last month.

What’s in NIST 800-171B?

Like 800-171, NIST 800-171B addresses the handling of Controlled Unclassified Information (CUI). Many types of information routinely handled by federal contractors are classified as CUI, from Social Security numbers and other PII to information related to a weapons system or other high-value assets (HVAs). The latter is the focus of 800-171B. CUI related to an HVA has a higher than normal risk of exposure and is the primary target for APT attacks by foreign cybercriminals, but the basic and derived requirements of 800-171 were not designed with APTs in mind.

An APT is a “long game” cyberattack where hackers remain undetected in a system for a significant duration in the pursuit of a specific goal. Perhaps the most well-known example of an APT is the Stuxnet virus, which infected the Natanz uranium enrichment plant in Iran, slowly, silently, and gradually destroying centrifuges over a long period of time.

The enhanced security requirements in SP 800-171B were derived from and map to the requirements in SP 800-53. They are centered around what NIST has identified as the key elements of defending against APTs, including:

• Developing security requirements specifications with a threat-centric approach
• Implementing logical and physical isolation using system and network segmentation techniques, virtual machines, and containers
• Implementing dual authorization controls for the most critical or sensitive operations
• Limiting persistent storage to isolated enclaves or domains
• Continuous monitoring and protection through an SOC that employs advanced analytics

Additionally, 800-171B recognizes the reality of the modern cyber threat environment. Hackers are relentless; the moment one vulnerability is shored up, they find another to exploit. Defense contractors, and all other organizations, must accept that no defenses are foolproof; despite taking every possible precaution, they will eventually be breached. In light of this, 800-171B instructs defense contractors to implement “safeguards and countermeasures to confuse, deceive, mislead, and impede the adversary,” such as misleading hackers in such a way that they question the authenticity of the information they are attempting to steal.

Defense contractors will implement the 800-171B requirements in addition to, not in place of, NIST 800-171. NIST notes that only a small percentage of defense contractors will be required to comply with 800-171B, and even then, the enhancements will apply only to systems that handle CUI associated with HVAs. However, the recommendations in 800-171B could be applied on a voluntary basis by private-sector organizations that wish to take advanced security precautions to protect their high-value digital assets.

NIST is accepting public comments on SP 800-171B through July 19, 2019.

The cyber security experts at Lazarus Alliance have deep knowledge of the cyber security field, are continually monitoring the latest information security threats, and are committed to protecting organizations of all sizes from security breaches. Our full-service risk assessment services and Continuum GRC RegTech software will help protect your organization from data breaches, ransomware attacks, and other cyber threats.

Lazarus Alliance is proactive cyber security®. Call 1-888-896-7580 to discuss your organization’s cyber security needs and find out how we can help your organization adhere to cyber security regulations, maintain compliance, and secure your systems.

NIST proposes a Secure Software Development Framework to address software supply chain attacks

Applying software updates and patches as soon as possible is a cyber security best practice, but what if an update contains malicious code inserted by a hacker? Software supply chain attacks are a serious and growing problem for both private-sector organizations and the federal government. Among other incidents, Chinese nation-state hackers successfully breached numerous third-party contractors working for the U.S. Navy on multiple occasions over an 18-month period.

The Navy contractor attacks and similar incidents were the impetus for the federal government barring agencies from purchasing certain vendors’ software and hardware. However, these bans don’t address the root of the problem, which is that security must be baked into the software development lifecycle (SDLC) from the very beginning. This is why NIST has proposed a Secure Software Development Framework (NIST SSDF).

What’s in the NIST SSDF?

While there are many SDLC frameworks, few specifically address secure software development; they were designed to speed up and bring order to the development process, not ensure security. Instead, project managers are left to integrate secure development practices on their own.

The proposed NIST SSDF does not introduce any new practices. It curates high-level secure software development best practices from a number of existing sources. So that the framework is flexible, it does not specify how to implement its recommendations. Implementation will look different in every organization, as data environments, security objectives, and priorities greatly differ.

The proposed framework includes 19 best practices for secure software development, grouped under four categories.

Prepare the organization. The best practices in this category are about aligning the organization’s people, processes, and technology to build a strong foundation for secure software development. It outlines practices such as ensuring that security requirements for software development are known at all times so they can be taken into account throughout the SDLC; making sure that everyone involved in the SDLC knows what their roles and responsibilities are regarding secure development; and using automation to improve the accuracy, consistency, and comprehensiveness of security practices.

Protect the software. Software must be secured against tampering and unauthorized access, both intentional and accidental. The best practices in this category address how to secure source code for in-house projects and provide recommendations to aid end users in ensuring that the software they acquire is legitimate and has not been tampered with.

Produce well-secured software. The best practices in this category seek to maximize software security and minimize vulnerabilities in each release. Many developers have not been educated in secure development practices and end up unknowingly producing insecure code. In addition to addressing secure software development practices for in-house projects, it provides recommendations for verifying that third-party software meets security requirements.

Respond to vulnerability reports. This step focuses on identifying potential vulnerabilities in each successive release, addressing them, and preventing similar problems in future releases.

NIST hopes that the recommendations in the SSDF benefit both sellers and buyers in the software supply chain. Sellers who adopt secure software development practices will address the root causes of supply chain cyberattacks by minimizing potential vulnerabilities in each release and mitigating the impact of undiscovered vulnerabilities. Buyers can adapt these practices and incorporate them into their software acquisition processes.

The public comment period for the draft NIST SSDF began on June 11 and ends on August 5, 2019.

The cyber security experts at Lazarus Alliance have deep knowledge of the cyber security field, are continually monitoring the latest information security threats, and are committed to protecting organizations of all sizes from security breaches. Our full-service risk assessment services and Continuum GRC RegTech software will help protect your organization from data breaches, ransomware attacks, and other cyber threats.

Lazarus Alliance is proactive cyber security®. Call 1-888-896-7580 to discuss your organization’s cyber security needs and find out how we can help your organization adhere to cyber security regulations, maintain compliance, and secure your systems.