Friday, October 16, 2020


A critical component of securing an enterprise is a tool to concatenate and correlate the data from events across security logs and tools. This grew from what we used to call "Log Aggregation, Correlation, and Normalization". As the volume of data coming through these systems became unmanageable, the evolution of the tools started alerting on event types. 

 The newer tools are classified as either a SEIM or SIEM. While both acronyms identify a tool's basic functionality, I offer up an opinion that there are subtitle nuances to the tools with which places them in one of the other categories. While used almost interchangeably, when we look at the acronyms separately we see that they have a focus that fits differing objectives

• SEIM stands for Security Event and Incident Management, while 
• SIEM stands for Security Information and Event Management 

While both tools would do the basics of a SIEM and gather security information from the various tools and logs necessary to have a holistic look at events across the security landscape, I believe a tool that falls into the SEIM category would have greater functionality in not only identifying events but include a workflow engine and evidence handling capacity to facilitate incident management across the enterprise. 

One point that often gets overlooked by technologists is that responding to Incidents across the enterprise includes many steps taken outside of IT that also need to be captured, recorded, and forensically held in a defensible chain of custody. This workflow may be managed by non-IT or IT Security personnel. 

This cross-organizational workflow is a piece that is evolving at best and has brought the rise of Security Orchestration And Response (SOAR) platforms. Most SEIM vendors are focused on User and Entity Behavior Analytics (UEBA) which includes machine learning of baseline activities and alerts on anomalous behaviors. This automation, while useful and expands the potential to capture more activities that may be suspect, it does not help the "defensibility" of responding to an incident beyond the technical realm. (more on UEBA in another post). As a consumer, I would want my SEIM to include a SOAR functionality or at the minimum an integration into my enterprise workflow management platform. There are so many disconnected choices out there (from SOAR at the Firewall, Standalone products, or some limited functionality in some SEIM solutions) 

I have found there are two types of SEIM vendors - Mature Security tools that are trying to incorporate UEBA; and Mature UEBA tools trying to snap on SEIM functionality. Both of which have their challenges. It really comes down to the applicability of the functionality in your particular use case. If your SOC team has the ability to "swivel chair" for event and incident management logging and tracking then the more mature UEBA tool, which may have some limitations in SEIM and SOAR functionality, may be acceptable.

Friday, April 11, 2014

Asset Managers Prepare: SEC Cybersecurity Sweep Audits Are a Reality

With the recent announcement by Jane Jarcho, National Associate Director for the Securities and Exchange Commission's Asset Manager exam program, that they “will be looking to see what policies are in place to prevent, detect and respond to cyber attacks,” as well as vendor access and vendor due diligence from asset managers, the SEC has ramped up their Cybersecurity Assessment program out of their Chicago office.

The practice of Asset management, broadly defined, refers to any system that monitors and maintains things of value to an entity or group. The context of Jarcho’s statements was directed towards Investment Managers.

Investment management is the professional asset management of various securities (shares, bonds and other securities) and other assets (e.g., real estate) in order to meet specified investment goals for the benefit of the investors. Investors may be institutions (insurance companies, pension funds, corporations, charities, educational establishments etc.) or private investors (both directly via investment contracts and more commonly via collective investment schemes e.g. mutual funds or exchange-traded funds).

The new focus is to try to "require" asset managers to disclose Cybersecurity breaches. The focus on cyber events (which has traditionally been "guidance" but is now being pressured to become "rule") is being prepared to meet the registration filing process for "material changes" as described in the SEC guidance for Corporate Financial Disclosure, topic 2: Cybersecurity

From the SEC CF Disclosure Guidance Topic Number 2: Cybersecurity 

Disclosure by Public Companies Regarding Cybersecurity Risks and Cyber Incidents

The federal securities laws, in part, are designed to elicit disclosure of timely, comprehensive, and accurate information about risks and events that a reasonable investor would consider important to an investment decision. Although no existing disclosure requirement explicitly refers to Cybersecurity risks and cyber incidents, a number of disclosure requirements may impose an obligation on registrants to disclose such risks and incidents. In addition, material information regarding Cybersecurity risks and cyber incidents is required to be disclosed when necessary in order to make other required disclosures, in light of the circumstances under which they are made, not misleading. 3 Therefore, as with other operational and financial risks, registrants should review, on an ongoing basis, the adequacy of their disclosure relating to Cybersecurity risks and cyber incidents.

The SEC is ramping up to perform Sweep Assessments. These are very targeted assessments against very succinct criterion. In this case the SEC is looking to see if Asset Managers are “doing the right things”. This comes as no shock or revelation to Cybersecurity professionals but Asset Managers have never really been held “accountable” for Cybersecurity in the past. Many Investment Managers strive to follow standards and industry accepted practices but they find they may not have such tight control over their Broker/Dealer networks. Alliance partner attestations of Cybersecurity control alone will not indemnify the brand and reputation following an incident. Due diligence and focus on standards becomes more and more important as the regulatory scrutiny increases.

Some of the items the SEC will be asking the Investment Managers to provide seems rudimentary to a Cybersecurity professional but may not be as readily accessible to some organizations. Getting an early start on identifying and compiling the pieces of evidence being asked for is key to not only a successful Cybersecurity focused Sweep Assessment but also to double check, validate or shore up a comprehensive Cybersecurity program. Having a third party assist in interpreting this evidence and ensuring the objective for the requests will ease the pain and confusion that may precede a formal assessment.

Some highlights from the SEC’s list of items they will be asking for are:

Relevant Policies and Procedures for:
Physical Device Inventory
Software platform and application inventory
Network Maps
Cataloging of External Connections to the network
Resource Classification based on risk
Logging capabilities
Written Security Policy
Risk Assessment Processes
Cybersecurity threats
Physical security threats
Systemic Cybersecurity roles and responsibility/accountability
Business Continuity Plan
Cybersecurity Ownership/Leadership (CISO or equivalent)
Cybersecurity Insurance maintenance and coverage
Cybersecurity Risk Management (adherence to Standards)
Cybersecurity Network Controls, testing and Staff Training
Application Development
Configuration Standards
Distributed Denial Of Service resiliency
Data Retention and Destruction
Incident Response
BCP and DR
Risks associated with Remote Customer Access and Asset Transfer Requests
Online Access
Identification Authentication and Access Management
User Credential protection
E-mail authentication
Risks associated with Vendors and Third Parties
Detection of Unauthorized Activity
Documentation of any incidents since January 1, 2013

There is much more detail they will be requesting to support the topics highlighted above. Bottom line here is that the SEC is looking to see that the organization is following industry accepted practices for Cybersecurity. Identifying supporting evidence will greatly reduce the frustration and churn that may result from being subjected to these sweep assessments. My advice is to get a jump on this expectation by identifying and validating the supporting evidence early.

Friday, April 4, 2014

CRO - Not just for City Planning?

Just a few short years ago “convergence”, in the Cybersecurity world, was bantered about as a single word descriptor for the union of physical and logical security. It was inevitable that we would want to correlate who is logged onto our network and when they arrived or left our buildings. From this revelation came the birth of the Chief Security Officer (CSO).

Another convergence is now the buzz in our journey toward Cybersecurity. It may very well be time for another revelation in that IR and BCP are naturally tied to one another in more ways than simply the occurrence of an event. From a Cybersecurity management perspective the big question is, does this beckon for the creation of a Cybersecurity Chief Resilience Officer (CRO)?

Back in the 1960’s and 1970’s, we went through great pains to ensure we backed up our systems on tape drives, disk packs, what ever we could to save our work, critical digital assets and livelihood from disasters. As we were called to employ our back up tapes we realized that the back ups were only part of the complex puzzle. We matured Disaster Recovery (DR) into Business Continuity Planning (BCP) and eventually, Business Resiliency Planning (BRP). This allows us to prepare a comprehensive set of decision making tools and plans for what might happen.

In the current threat landscape, data breaches and intrusions are more prevalent than ever. This has highlighted the need for a well planned, orchestrated and in some cases pre-scripted, incident response plan.  We need to define steps to take, what talent pools are necessary to respond, whom to notify and how to minimize the impact on our business. This necessitates that we prepare a comprehensive plan for what will happen.

Both BCP and IR planning are closely tied to business and technology, but both have very different resource needs. Successfully crafting these plans will take expertise from very different parts of an organization. The BCP is, by definition, a business plan. Therefore deep business prowess is required. The IR plan, on the other hand has deep technical aspects and legal ramifications that require very specialized IT and legal resources. The breadth of specialties necessary to develop and maintain these plans only compounds the challenge in keeping these plans truly alive in an organization. These plans need to feed and grow off one another.

An incident that requires attention may also have a direct impact on an organization’s ability to continue to do business securely. The fail over techniques or out of band data processing capabilities defined in a BCP may be appropriately invoked, or some notification trees developed in the BCP may very well be used in the IR plans.

Once the correlation between the planning processes are articulated, it become apparent that the convergence of the two disciplines augments the effectiveness of both.

I would venture to say that, with the current pace of IR that has become necessary, and the severity of impact to a given organization is realized we will start to see these two activities being headed up by a common lead within very large organizations (not just business, not just IT). So... maybe the CRO is not just for city planning anymore.

Thursday, April 3, 2014

Zero Day

<this is an older blog from another site to which I post>

In a special report, the Washington Post focused on zero-day attacks and how they can happen.  In particular, the report spends time on two case studies.  The first focuses on the Shodan search engine, which, in 2009, took on a project to map the devices linked to the Internet and exposed the fact that many Industrial Control Systems (ICSs) were connected and incredibly vulnerable to hackers. The second case study is the 2010 Stuxnet attack on an Iranian nuclear processing facility in which an infected thumb drive located four zero-day spots in the ICS and caused centrifuges to self-destruct. Attacks such as these on ICS keep security experts up at night, for good reason.

ICSs are a complex problem because they were never designed or intended to be integrated with the business  network thereby potentially exposing the process controls to the internet.  They were built with an intentional “air gap” to provide security.  Now, however, as budgets decline almost universally and business are leveraging sustainability to drive operations efficiencies, businesses increasingly are adding “smarts” to their systems for buildings, fleets, plant operations, supply chains. These smart systems are often networked together as part of efforts to reduce workforces, lower costs and increase efficiencies. Because configuring these networks and the devices that comprise them is incredibly complex, the ICSs are inadvertently being connected to the Internet leaving them vulnerable to attack.

Security professionals who want to protect ICSs have a special challenge. The systems generally are decades old and do not allow for automated discovery of their configurations and interconnections. And yet, you can't protect what you don't understand.

Fortunately, the situation is not as impossible as it sounds. Choosing between business efficiencies and Cybersecurity is not necessary.  The answer to fighting zero-day attacks and malicious activity in this era of budget minimization is to "do the right things" when it comes to security. This means covering all the bases and remaining vigilant. It means being smart about smart systems. It means being creative.  For example, although traditional network mapping is not possible for ICS, security experts can leverage maintenance management systems and records to get a more clear idea of how the environment has evolved and where the subsystems are connected; to identify where the ingress and egress points in the system are located; and to perform periodic risk assessments of the system. Awareness of where the vulnerable systems are, and truly knowing how the components are connected, will shed light on potential holes in the ICS environment that may lead to exposure of vulnerabilities to the outside world. Performing assessments with a consequential risk basis will also help identify the systems, subsystems and components that wield the most impact if compromised. This allows the security professional to take action in mitigating these conditions. In the ICS arena, there are many times where simply remediating the vulnerability is not an option. Therefore, alternative mitigation strategies may need to be employed.

These steps (and a little creativity) can help to locate zero-day vulnerabilities, manage the risks associated with new and emerging “smart” systems, and derive savings by operating more sustainably.

So you want Cybersecurity Insurance?

Many years ago I was taught that one can only do three things with risk — eliminate, mitigate or transfer it. With the increase in attacks on automation technologies by those intending to compromise industrial control systems (ICS), such as supervisory control and data acquisition (SCADA) systems, and distribution control and process control networks, the majority of our collective attention has been on the first two areas of risk. Now, with the insurance industry beginning to cover cybersecurity risk, companies will find they can consider the third area, and transfer risk, if their cybersecurity is appropriate to their risk posture.
Lloyd’s of London recognized recently the need to address the potential for property damage or production loss due to a cyberterrorism attack. In February 2014, BBC News reported that the insurance company is denying coverage to power companies because of inadequate cyberdefenses. This emerging option for addressing risk will certainly put the onus back on owners and operators of ICS networks to know their risks and to also know how effectively their cybersecurity controls are working.
If companies find that this emerging option to transfer monetary risk is an attractive and viable solution to navigating the ICS cybersecurity labyrinth, they should also be prepared to look closely at their operating technology (OT) environments. It’s clear that, as insurance options mature, insurance companies will emphasize risk assessment and control validation.
ICS security pundits argue both pro and con when it comes to the value of conducting detailed risk assessments on OT environments. After all, business value is what we are here to protect, along with personnel and community safety. However, the ability to secure at least a portion of corporate peace of mind by transferring monetary risk to insurance policies should greatly augment the pro side of this risk assessment argument.
If companies want to transfer part of their risk, insurance will help drive the need to prove that their controls are in the right place and working. A formal and repeatable risk-assessment and standards-compliance process, such as the ICS Cybersecurity Assessment program we have pioneered with our current clients, will enable companies to make that risk transfer feasible.

Friday, October 22, 2010

Living With Dichotomy

One of the most prominent challenges a true security professional encounters when looking into Industrial Control System (ICS) Security is the dichotomous relationship between process control engineers and the traditional IT security support staff. In reality both sides have the same objective in mind, however the focus and approach differs greatly. IT security teams tend to focus on security of information and have a hard time detaching from that mind set, while process control teams tend to insist that security measures hinder the ability to perform their duties efficiently and safely. Both teams speak from experience yet both teams speak half truths when it comes to ICS security.

As in many things in life, a happy balance is necessary to succeed in securing an ICS. Good solid process and accountability is the best offense and defense. Traditional IT Security measures must be balanced with compensating controls to accommodate the safety and availability challenges in the ICS world. Basics like password complexity, rotation and even use must be rethought to satisfy the basic purpose and function of these systems.

Risk assessment driven policy and process, however is always a prudent approach. Identification of the most critical systems, ones with the highest impact on health/safety, financial loss, environmental hazards, production loss and public image is essential to be able to address the assets that effect the overall security of the organization.

The risk assessment process in its self can be a bridge in the gap between the IT and Process Control groups. Leveraging the opportunity to bring these sides of the house to a single conclusion on meeting the challenges is a good start By having them collaborate on the importance of assets and talking through the challenges in security, eyes are opened on both sides of the aisle when it comes to the true use and operational challenges with these systems.