The action was prompted by the Android malware spreading aggressively through SMS around the world

Read More

A year after the ransomware attack against the Colonial Pipeline, what can we do to further harden the IT and OT systems of power plants, fuel pipelines, water treatment plants and similar critical infrastructure facilities?

The Colonial Pipeline’s shutdown after a ransomware attack in May 2021 put a massive spotlight on the importance of protecting the IT and OT systems of critical infrastructure providers. 

With major disruptions to gasoline, diesel and jet fuel distribution across multiple U.S. states lasting about a week, the incident prompted reactions at the highest levels of government and industry, including the drafting of new rules and regulations.

A year later, the initial shock of the Colonial Pipeline hack has passed, but the concern remains very much front and center. What can we do to further harden the cybersecurity of power plants, fuel pipelines, water treatment plants and similar facilities? 

As someone who worked as an ICS engineer – tasked with building, maintaining and troubleshooting industrial control systems – before specializing in OT cybersecurity, the issue is near and dear to my heart.

I’ve recently participated in discussions about this matter, including in a podcast and a LinkedIn Live session, and I’d like to share here some concrete steps I’ve talked about that we can all take – the U.S. government, CISOs, cybersecurity vendors and the public at large.

CISOs, CIOs and business leaders

CISOs, CIOs and business leaders at these critical infrastructure providers must recognize that, as the operations in these plants and facilities get increasingly digitized, more resources must naturally be allocated to cybersecurity. I’m not necessarily advocating for an increase in cybersecurity spending, but rather that it should be prioritized on the “crown jewels,” which in my mind are the OT and ICS systems.

IT and cybersecurity leaders must also recognize that the most critical component in the cyber protection of OT systems is the people involved in it. As such, you can’t expect ICS engineers with no training or experience in cybersecurity to add on cybersecurity tasks to their regular job of keeping the plant running. You need a dedicated, experienced and trained team for OT cybersecurity.

Once you have OT cybersecurity specialists on board, you should make sure they shadow their ICS engineers peers, so that they can get a hands-on understanding of how the facility operates, and a clearer sense of the implications that cybersecurity decisions can have on operations.

It’s critical to have full visibility into all IT and OT systems – not just the prominent, obvious ones like enterprise applications, web servers and billing environments. Your weakest link is often a system that’s tucked away in a closet or hidden under a desk and that was once installed as a stopgap and promptly forgotten, so it’s underprotected. You must make an effort to compile a comprehensive inventory of all your systems, and gain an understanding of the role each one plays.

Fix or mitigate your vulnerabilities, because they’re the low-hanging fruit that ransomware operators look for, and ICS environments are particularly at risk due to the prevalence of legacy software in them.

Vendors 

ICS vendors must make their wares more secure. Many legacy ICS systems are insecure by design. They should be re-designed from the ground up with default security features and capabilities, such as secure protocols and approved mechanisms for authenticated firmware updates. 

OT cybersecurity vendors must recognize that the ultimate goal of the technology they market is to keep critical infrastructure safe for the benefit of everybody in our society. As such, they should compete on the merits of their products, not on imposing proprietary technology that locks customers into their vendor ecosystem. Equally as important is to have a spirit of cooperation and open communication, despite their competitive differences, so that they can collaborate on advancing OT cybersecurity technology that better protects critical infrastructure. That’s why at Tenable we helped launch the Operational Technology Cybersecurity Coalition, where we advocate for the development of vendor-neutral, interoperable, standards-based cybersecurity solutions. 

The U.S. government

It’s the role of the government to issue rules and regulations to ensure that a baseline standard of care is applied to safeguard the OT and IT systems of critical infrastructure providers. To be truly effective, these requirements should be outcome oriented – meaning, they should outline goals and achievements that should be attained. They’ll be less impactful if they’re overly detailed and prescriptive from a technical standpoint, because the government’s regulatory wheel typically turns slowly, and the mandates will soon become outdated, as the technology changes quickly.

The government does a great job of designing and carrying out exercises for its agencies to practice responses to crisis situations. It’d be great if the government shared its OT cybersecurity exercises with the private sector, which in turn could help the government better understand in more detail the wide variety of ICS deployments in operation across the country.

Regular citizens

The cybersecurity of our critical infrastructure should be everyone’s concern – even the large majority of people who aren’t in the first three buckets I addressed above. Here’s what you can do: Let your voice be heard. Get involved. Phone your state and local representatives. Participate in public forums where decision makers take feedback from residents. Be ready to have meaningful conversations with them. This isn’t someone else’s problem. It affects all of us.

If you’re interested in learning more about these topics, I invite you to listen to my recent conversations on the podcast The State of OT Security, a Year Since Colonial Pipeline with my Tenable colleague Dan Raywood, and on the LinkedIn Live session Colonial Pipeline One Year Later: What Have (and Haven’t) We Learned? with CNN cybersecurity reporter Sean Lyngaas.

You may also be interested in tuning into a transport-focused OT webinar we’re hosting on June 15 at 2 pm ET – Unpacking Some of the Most Common Cybersecurity Challenges Facing Your Transportation-Sector Business – with panelists from the U.S. Transportation Security Administration (TSA) and two of our partners. Sign up for this webinar today!

Read More

What is a logic bomb?

A logic bomb is a piece of code left lying in wait on a computer that will execute under certain specified conditions and take actions the owner of that computer would consider malicious. The actual code that does the dirty work, sometimes referred to as slag code, might be a standalone application or hidden within a larger program.

While logic bombs are sometimes delivered via the same techniques that can infect your computer with viruses or other malware, more often they’re planted by insiders with privileged access to the system being attacked—and can therefore be quite tricky to detect.

Are logic bombs viruses?

A logic bomb isn’t a virus, but it could be spread by one. Unlike a virus, the distinguishing characteristic of a logic bomb isn’t how it spreads, but how it’s triggered.

To read this article in full, please click here

Read More

Connecticut Governor Ned Lamont officially signed into law the so-called Connecticut Privacy Act

Read More

Extorters focus their efforts on a perceived soft target

Read More

Introduction

Since my previous blog CMMC Readiness was published in September 2021, the Department of Defense (DoD) has made modifications to the program structure and requirements of the Cybersecurity Maturity Model Certification (CMMC) interim rule first published in September 2020.  CMMC 2.0 was officially introduced in November 2021 with the goal of streamlining and improving CMMC implementation.

In this blog, I will identify the key changes occurring with CMMC 2.0 and discuss an implementation roadmap to CMMC readiness.

Key changes

Key changes in CMMC 2.0 include:

Maturity Model reduced from 5 compliance levels to 3

Level 3 – Expert
Level 2 – Advanced (old Level 3)
Level 1 – Foundational

Improved alignment with National Institute of Standards and Technology (NIST)

NIST SP 800-171
NIST SP 800-172

Practices reduced from 130 to 110 for Level 2 Certification
Independent assessment by C3PAO at Level 2 – Advanced
Self-assessment at Level 1 – Foundational, limited at Level 2 – Advanced
Removed processes (ML.2.999 Policy, ML.2.998 Practices, and ML.3.997 Resource Plan)

Figure 1. CMMC Model

Source: Acquisition & Sustainment – Office of the Under Secretary of Defense

CMMC requirements at Level 1 and Level 2 now align with National Institute of Standards and Technology (NIST) Special Publication (SP) 800-171 – Protecting Controlled Unclassified Information in Nonfederal Information Systems and Organizations.  This alignment should be beneficial to most DIB organizations since they have been subject to FAR 52.204-21 or DFARS 252.204-7012 and should have been self-attesting to NIST SP 800-171 practices whether it be the 17 NIST practices required for those handling only FCI or the 110 NIST practices for those handing FCI and CUI.  Those organizations that took self-attestation seriously over the years should be able to leverage the work they have previously performed to place themselves in a strong position for CMMC certification.

CMMC 2.0 may have dropped the three Processes (ML.2.999 Policy, ML.2.998 Practices, and ML.3.997 Resource Plan), but that does not eliminate the requirement for formal security policies and control implementation procedures.  CUI security requirements were derived in part from NIST Special Publication 800-53 Security and Privacy Controls for Federal Information Systems and Organizations (NIST SP 800-53).  The tailoring actions addressed in Appendix E of NIST SP 80-171R2 specify that the first control of each NIST SP 800-53 family (e.g., AC-1, AT-1, PE-1, etc.), which prescribe written and managed policies and procedures, are designated as NFO or “expected to be routinely satisfied by nonfederal organizations without specification”.  This means that they are required as part of the organization’s information security management plan and are applicable to the CUI environment.  Refer to Appendix E for other NIST SP 800-53 controls that are designated as NFO and include them in your program.

Implementation roadmap

Although there have been welcomed changes to the structure of CMMC, my recommended approach to implementation first presented last September has changed little.  The following presents a four-step approach to get started down the road to CCMC Level 2 certification. 

Education

I cannot stress the importance of educating yourself and your organization on the CMMC 2.0 requirements.  A clear and complete understanding of the statute including the practice requirements and the certification process is critical to achieving and maintaining CMMC certification.  This understanding will be integral to crafting a logical, cost-effective approach to certification and will also provide the information necessary to effectively communicate with your executive leadership team. 

Start your education process by reading the CMMC 2.0 documents relevant to your certification level found at OUSD A&S – Cybersecurity Maturity Model Certification (CMMC) (osd.mil).

Cybersecurity Maturity Model Certification (CMMC) Model Overview Version 2.0/December 2021 – presents the CMMC model and each of its elements
CMMC Model V2 Mapping Version 2 December 2021 – Excel spreadsheet that presents the CMMC model in spreadsheet format.
CMMC Self-Assessment Scope – Level 2 Version 2 December 2021 – Guidance on how to identify and document the scope of your CMMC environment.
CMMC Assessment Guide – Level 2 Version 2.0 December 2021 – Assessment guidance for CMMC Level 2 and the protection of Controlled Unclassified Information (CUI).

Define

The CMMC environment that will be subject to the certification assessment must be formally defined and documented.    The first thing that the CMMC Third-Party Assessor Organization (C3PAO) engaged to perform the Level 2 certification must do is review and agree with the CMMC scope presented by the DIB organization.  If there is no agreement on the scope, the C3PAO cannot proceed with the certification assessment. 

Scope

CMMC environment includes all CUI-related associated assets found in the organization’s enterprise, external systems and services, and any network transport solutions.  You should identify all of  the CUI data elements that are present your environment and associate them with one or more business processes.  This includes CUI data elements provided by the Government or a Prime Contractor, as well as any CUI created by you as part of the contract execution.  Formally document the CUI data flow through each business process to visualize the physical and logical boundaries of the CMMC environment.  The information gleaned during this process will be valuable input to complete your System Security Plans (SSPs).

Not sure which data elements are CUI?  Work directly with your legal counsel and DoD business partner(s) to reach a consensus on what data elements will be classified as CUI.   Visit the NARA website at (Controlled Unclassified Information (CUI) | National Archives) for more information concerning the various categories of CUI.   Ensure that the classification discussions held by the team and any decisions that are made are documented for posterity. Do not forget to include CUI data elements that are anticipated to be present under any new agreements.

Figure 2. High-Level CMMC Assessment Scope

Based on image from CMMC Assessment Scope – Level 2 Version 2.0 | December 2021

During the scoping exercise, you should look for ways to optimize its CMMC footprint by enclaving CUI business processes from non-CUI business processes through physical or logical segmentation.  File and database consolidation may be helpful in reducing the overall CMMC footprint, as well as avoiding handling CUI that serves no business purpose.

GCC v GCC High

Heads up to those DIB organizations that utilize or plan to utilize cloud-based services to process, store, or transit CUI. The use of cloud services for CUI introduces the GCC vs. GCC High considerations.  The GCC environment is acceptable in those instances where only Basic CUI data elements are present.  GCC High is required if CUI-Specified or ITAR/EAR designated data elements are present.  In some instances, prime contractors that utilized GCC High may require their subcontractors to do the same.

Asset Inventory

Asset inventory is an mandatory and is an important part of scoping.  The table below describes the five categories of CUI assets defined by CMMC 2.0.

Asset

Description

CUI

Assets that process, store, or transmit CUI

Security Protection

Assets that provide security functions or services to the contractor’s CMMC scope.

Contractor Risk Managed

Assets that can, but are not intended to process, store, or transmit CUI due to security controls (policies, standards, and practices) put in place by the contractor.

Specialized

Special group of assets (government property, Internet of Things (IoT), Operational Technology (OT), Restricted Information Systems, and Test Equipment) that may or may not process, store, or transmit CUI.

Out-Of-Scope

Assets that cannot process, store, or transit CUI because they are physically or logically separated from CUI assets.

DIB contractors are required to formally document all CUI assets in an asset inventory as well as in their SSPs.  There are no requirements expressed for what information is to be captured in the inventory, but I would recommend in addition to capturing basic information (i.e., serial numbers, make, models, manufacturer, asset tag id, and location) you consider mapping the assets to their relevant business processes and identify asset ownership.   Owners should be given the responsibility for overseeing the appropriate use and handling of the CUI-associated systems and data throughout their useful lifecycles.  An asset management system is recommended for this activity, but Microsoft Excel should be adequate for capturing and maintaining the CUI inventory for small to midsize organizations.

Figure 3. Asset Inventory

Assess

Once you have your asset inventories completed and your CMMC scope defined, it’s time to perform a gap analysis to determine your security posture alignment with CMMC requirements.  If you have been performing your annual self-attestation against NIST SP 800-171, you can leverage this work but be sure to assess with greater rigor.  Consider having a CMMC Registered Practitioner from a third-party provider perform the assessment since will provide an unbiased opinion of your posture.  The results of the gap assessment should be placed into a Plan of Action and Milestones (POAM) where you will assign priorities, responsibilities, solutions, and due dates for each gap requiring corrective action.

Remediate

Finally, use the POAM to drive the organizations remediation efforts in preparation for CMMC certification.  Remember that if you contract 3rd-party services as part of remediation (e.g., managed security services, cloud services, etc.) those services become part of your CMMC scope.  Consider performing a second posture assessment after remediation efforts are complete to ensure you are ready for the certification assessment by the C3PAO.  CMMC certification is good for 3 years, so be sure to implement a governance structure to ensure your program is positioned for recertification when the time comes.

Conclusion

I hope this implementation roadmap provides a benefit to you on your CMMC Level 2 certification journey.  Keep in mind, there are no surprising or unusual safeguards involved in the process as CMMC requirements align with industry best practices for cybersecurity.  As with any strong information security program, it is critical that you fully understand the IT environment, relevant business processes, and data assets involved.  As we like to say in cybersecurity, “you can’t protect an asset if you don’t know what it is or where it’s at”.  Completing the upfront administrative work such as education, scope, and inventory will pay dividends as you progress toward independent certification.

Read More

If you have a traditional domain, it’s time to audit your Active Directory. In fact, it’s probably way past time. You probably have accounts that have been unchanged for years and might not have reviewed settings or registry entries. Attackers know that these domains have legacy settings that allow them to take greater control and use techniques to gain domain rights. Active Directory security came into the news with the release of several updates in May, you need to take many more steps than mere patching to protect your network.

Microsoft’s server tools include Best Practices Analyzer (BPA), but it doesn’t identify some of the means that attackers use to go after Active Directory domains. Several other resources analyze the health and security of Active Directory domains including Purple Knight from Semperis, PingCastle, or Quest’s Active Directory health check tool.

To read this article in full, please click here

Read More

The lawyers continue to gather their billable hours as the legal tussle between data science company hiQ Labs and LinkedIn plays out in the United States federal courts. The most recent update took place in the Ninth Circuit Court of Appeals, with Judge Marsha Berzon writing the opinion, where hiQ Labs was granted a continued preliminary injunction, which would allow the company access LinkedIn’s publicly available corpus of data. The ruling also remanded the companies for further proceedings on the subject. In addition, the court held that hiQ’s actions do not violate the U.S. Computer Fraud and Abuse Act (CFAA).

To read this article in full, please click here

Read More

Digital transformation and remote working take their toll

Read More

Funds were funnelled from invoice fraud and crypto scams

Read More