Home - ARC Cyber Security Insights by Bob Mick

2/19/2010

ICS Cyber Security at ARC’s 2010 Forum

By Robert Mick, ARC Advisory Group

ARC held its 2010 Forum last week (Feb 8-11) in Orlando, Florida with more cyber security content than ever before. This signifies a growing general interest in cyber security for ICS (Industrial Control Systems), and also a growing investment in cyber security research at ARC. However there were signs that the ICS security community is not growing sufficiently to match industry needs.

ARC security content was kicked off on Monday with a workshop designed to stimulate rethinking. We examined vulnerability and human factors research from Idaho National Labs and the role of automation vendors. A more detailed report can be viewed at ARC Cyber Security Insights.

Tuesday morning Marty Edward of DHS started the general session thinking about cyber security by recounting the history of control systems and how that opened the door to cyber attacks. Marty’s well received comments are summarized under Highlights from the ARC 2010 Orlando Forum General Session.

Tuesday afternoon included an entire track on ICS security, comprised of two sessions that addressed a few opportunities for improving ICS cyber security. The first session addressed the opportunities associated with the use of third party security services for ongoing operations, and the value of ICS device certification and testing. See Rethinking Cyber Security at ARC’s 2010 Forum – Opportunities.

The second session reviewed the Energy and Chemicals Industry Roadmaps for cyber security, and the opportunity of cross-industry sharing, and this can be viewed at Energy and Chemicals Industry Cyber Security.

All the above blogs and more may be found here.

If you are interested in participating in future ARC activities on cyber security, please let me know at Bob Mick.

Posted at 10:32 AM by Steve Clouther | Category: Industry Activity | Permalink | Email this Post | Comments (0)

2/18/2010

Rethinking Cyber Security at ARC’s 2010 Forum – Industry Roadmaps

This is the third and final posting about Industrial Control System (ICS) cyber security topics at last week’s Forum in Orlando. The first posting discussed the Monday afternoon ICS Workshop and the second discussed the first session on Tuesday afternoon about Cyber Security Services and ICS Device Compliance and testing. This posting covers the second session on Tuesday afternoon, including the Cyber Security Roadmaps for the Energy and Chemical Industries.

We actually had two purposes in mind. We wanted an update on the roadmaps, but perhaps more important we wanted to explore the opportunity for cross industry collaboration and the benefits for lagging industries to gain from the leaders. The DHS specified critical infrastructure industries have already broken new ground and even some of those are ahead of others.

Each critical infrastructure industry has a corresponding US government agency, Sector Specific Agencies (SSA) that is responsible for the coordinating the development of their industry roadmap. The roadmaps are all about setting high level goals and monitoring progress toward them.

The Energy was One of the First

Keith Stouffer of the National Institute of Standards and Technology (NIST) brought us up to date on the activities in the Energy Sector. The Energy Sector Roadmap was first developed in 2006 and they have recently been revising it in 2009 to reflect progress and set new goal. Much of the Energy industry standards work has been done within the North American Electric Reliability Corporation (NERC) as contained in the Critical Infrastructure Protection series (CIP-1 through CIP-9). These documents are relatively specific. For example, they require the use of antivirus software and testing. Revision 2 of these documents have been under development since 2008 and some have been approved. Work on Revision 4 is now underway. These standards are more than guidance documents and have related penalties for non-conformance. Theoretically, the penalties can be very large ($20,000 to $1,000,000 per day) for high risk, high severity situations, but Keith reports that the largest are very unlikely to be applied.

Keith also introduced us to the NIST plan for Smart Grid. This is a three phase plan that started in 2009 and extends through 2010 with planned efforts beyond that. One of the important NIST activities is the development of the NIST Interoperability Framework (see picture) that ranges from business requirements to compliance and testing. As you might expect there is considerable interest in Smart Grid activity and participation is high – over 300 participants in seven working groups.

The Chemical Sector

Eric Cosman of The Dow Chemical Company brought us up to speed on the the Chemical Sector roadmap and activities. A majority of the Chemical Sector security activity tales place around standards within ISA, ISO and IEC, guidance and advocacy within the ICSJWG (ICS Joint Working Group) and regulations within the Responsible Care and CFATS (Chemical Facility Anti-Terrorism Standards) programs.

Chemical companies have been involved in improving security for many years, including defining standards for the industry. Typically twenty or so major chemical companies participate in activities. Initially, security work was done within CIDX, an industry organization that has now merged into other organizations. Their security deliverables move to ChemITC several years ago. The DHS Chemical SSA is responsible for the Industry roadmap and work has leveraged the Energy Industry work wherever possible. The Roadmap document is available online. For 2010 the Roadmap focus is implementation oriented.

Observations

The Energy and Chemicals industries cyber security activities are relatively mature and participation is high. But most of the participation has been larger companies and one objective is to increase participation of mid-size and smaller companies – security issues are similar and the risk is often the same. This is a scaling challenge for DHS.

Non-critical Infrastructure Industries have been pretty much left to deal with cyber security on a voluntary bases. However, you should be aware that the list of critical infrastructure industries can grow and broaden in scope as government feels that it is necessary. The list started with 17 categories and a new one was added a couple of years ago. It is likely that new industries will not have as much time as the ground breakers to get up to speed, and all industries should be tracking standards and regulations in the critical infrastructure industries. It is also a good test of your cyber security strategy.

Actions

The critical infrastructure industries are on track to be well monitored relative to cyber security. But we need to finds ways to increase involvement of other companies. Mid-size companies will be a special challenge and different approaches are needed to be effective.

Posted at 4:19 PM by Bob Mick | Category: Industry Activity | Permalink | Email this Post | Comments (0)

Rethinking Cyber Security at ARC’s 2010 Forum - Opportunities

This is the second posting about Industrial Control System (ICS) cyber security topics discussed at last week's ARC Forum in Orlando. The first posting discussed the ICS Security Workshop on Monday Feb 8. On Tuesday, we spend another entire afternoon exploring three promising opportunities in ICS Cyber Security. The afternoon was broken into two sessions. The first session addressed the use of third party security services and the certification of ICS devices. This posting is about the first session. Session 2, Energy and Chemical Industry Roadmaps will be covered in another posting.

Using Third Party Security Services for ICS

Several types of third party security services are available, including security assessments, system design, implementation, managing infrastructure, and others. Most services are project oriented and used commonly. However, it appears that services for ongoing ICS operations are underused relative to the value they offer. DuPont has been using third party services since 2002 for managing some of their process control network (PCN) firewalls, and we asked Tom Good of DuPont to present their perspective to us.

DuPont wanted to achieve a step change in ICS security in 2002 and looked for third party security service provider with ICS experience, rather than wait until DuPont had built the necessary skills and processes internally. In 2002, DuPont engaged the expertise of Industrial Defender who initially helped shape DuPont’s firewall segmentation architecture and strategy. The first benefit was that it lowered their initial implementation cost. There were several other ongoing benefits, such as bring automated tools for monitoring and managing firewalls, and providing a discipline for change management, backups and emergency responses. One key result was achieving 24/7 support under a formal service level agreement. Importantly, DuPont and Industrial Defender developed a partnership approach with a co-management strategy that included sharing of expertise and ideas. Industrial Defender is now managing about 150 DuPont firewalls in process control networks across 90 sites, and DuPont is refreshing their installed firewalls.

ICS Device Certification and Testing

Industrial control systems are the last line of defense against intrusions, but legacy systems were not designed with security in mind. Even today, many control system components have not been thoroughly tested for vulnerabilities. Furthermore, attacks change and new vulnerabilities are discovered all the time. With this in mind, one opportunity for improving security is to develop formal security requirements with certification testing. ExxonMobil developed an Industrial Automation and Control (IACS) security vision, including a “secure by design” goal, and we asked Johan Nye of ExxonMobil to tell us how compliance testing fits within that vision.

Johan first pointed out that not all ICS vulnerabilities are within the devices themselves. Frequently, the systems do not adequately define roles, give admin privileges to operators, use passwords that cannot be changed online, and come with unused services enabled. It is also common to protect the user interface but provide no protection for ICS servers. One of the reasons for all this is the lack of guidance for automation systems vendors. Standards and compliance testing are one solution that will not only give vendors guidance but also will enable an independent verification process, specifically designed for ICS. A key strength to this approach is that the process of developing standards and processes can utilize the best security expertise across the industry rather than each buy defining vendor requirements independently.

Panel Discussion

After their presentations, Tom and Johan joined a panel discussion with three other industry experts: Andrew Ginter of Industrial Defender, Eric Byers of Byers Security, and Tyler Williams of Wurldtech Security Technologies. Andrew added his experience-based perspective on security services and other IC security elements offered by his company; Eric, relatively new in the role of product vendor, discussed the history of compliance and testing; and Tyler talked about how WST has been helping secure ICS components while the industry waits for standards to be developed. The panel also discussed issues such as why security services for ongoing operations were not more widely adopted, alternative to standards based compliance and testing processes, and who should bear the burden of testing.

Observations

I came away from the session believing more strongly that outsourcing security services, especially for ongoing activities, has great potential for improving the security of ICS systems. Cyber security is getting increasingly complex, requiring higher levels of training to keep up. It is difficult to imagine manufacturing, utilities and other such facilities being able to internally maintain highly trained security staff on multiple sites, and be vigilant 24/7 to monitor and react to problems.

The strongest case for certification and testing of ICS components appears to be in providing consistent expectations to ICS vendors. But inevitably, there is a danger that some will believe that certification assures security. On the contrary, device level security measures must be surrounded by several other security measures and processes. There is also a danger testing requirements may need to be broader and more dynamic than standards bodies are able to achieve with working groups staffed largely with volunteers. Certainly thorough testing will improve the security of ICS components and systems, and both vendors and end users are on a path to do so, mostly stimulated by the success safety systems that addressed similar issues several years ago. But it is only one piece of the very dynamic ICS security puzzle.

Actions

All of the session speakers, panel members and most of the session attendees have been contributing to ICS security communities for several years. They are true security experts and this enabled Forum discussions to start at a relatively advance level. However, other owner-operators and end users are experiencing ISC security issues and can gain substantially by increasing their involvement in industry activities. We intend to shape ARC ICS security research to help grow this community. If you can participate in any way in future activities, please let me know bmick@arcweb.com.

Posted at 1:08 PM by Bob Mick | Category: Industry Activity | Permalink | Email this Post | Comments (0)

2/17/2010

Rethinking ICS Cyber Security at ARC’s 2010 Forum – the Workshop

ARC held our 2010 Forum last week (Feb 8-11) with more cyber security content than ever before. This signifies a growing general interest in cyber security for ICS (Industrial Control Systems), and also a growing investment in cyber security research at ARC. However there were signs that the ICS security community is not growing sufficiently to match industry needs. This is the first of a serious of postings capturing what happened in Orlando.

Rethinking ICS Cyber Security Does Not Mean Starting Over

Our "Rethinking" theme was intended to give reason to pause briefly, think about the fundamentals, consider the current state of ICS security and explore opportunities for accelerating progress. It does not mean starting over, but may mean rebalancing investments in time and budget.

To facilitate re-thinking we invited several industry cyber security leaders to present, participate in panel discussions, and participate in a workshop. Here is a summary of the workshop that was conducted on Feb 8th.

Workshop Strategy

Our workshop strategy was to explore a few security fundamentals, and we invited Miles McQueen of Idaho National Labs to present two of his basic research areas: the nature of vulnerabilities and human factors. Some participants were a little apprehensive about mixing academic research with a largely tactical audience. They were pleasantly surprised when the combination proved to be very productive for the audience as well as for Miles. There were at least three impromptu follow up meetings at the Forum.

The second part of the workshop was led by Ernie Rakaczky of Invensys Operations Management (IOM). Ernie had not spoken in any of our security sessions previously, and we asked him to present the automation supplier perspective, more than an Invensys perspective. Ernie has contributed in many key ICS security activities in collaboration with his competitors for many years, making him well suited for the challenge. He bravely presented his views to them, as well as the end user participants, for consideration, discussion and debate – and there was plenty.

Workshop Observations

I will offer a few of my observations:

It would be difficult to listen to Miles' discussion of human factors and not get a heightened appreciation for the importance of considering human vulnerabilities in ICS security strategies. More must be done and it was not debatable.
My second observation was that the role of automation suppliers in achieving secure systems is not well defined and certainly expectations are not consistent. This clearly was a debatable issue, and consumed a good part of the open discussion period.
Finally, we did not intend to discuss incident reporting and vulnerability disclosure, but the topic came up and it is clear that these will continue to be hotly debated for some time to come.

Actions

The purpose of the workshop was to help participants think differently about ICS cyber security and this is hard to measure. My take is that the format worked, but participants ranged from companies looking for ways to strengthen their security programs to industry security experts. Consequently, everyone left with something different. For those of you that attended, let us know what you think: bmick@arcweb.com

From an ARC perspective, we feel that all of the items above deserve more visibility and we intend to invest in additional research and publications for all three over 2010.

My next posting will be about the Forum's Security Track.

Posted at 8:35 AM by Bob Mick | Category: Industry Activity | Permalink | Email this Post | Comments (0)

1/27/2010

Oil Companies Targeted in 2008 - Espionage

While I do not intend to post every attack and intrusion, it is important to look at some incidents when enough information is disclosed to learn something. A recent story posted Jan 25, 2010 by Mark Clayton of The Monitor about attacks (in 2008) on large oil companies is worth discussing because it reinforces a few important lessons.

First, this is about espionage not impacting operations or triggering physical damage of some sort. The attackers were trying to acquire information about oil fields that cost the oil companies a lot of money to develop.

Second, the attack was targeted at executive. The strategy was to take advantage of the fact that executives usually have free access to critical business information. After all, it is hard to tell a senior executive that he/she cannot be trusted with company information. The lesson is to limit access to information based on exposure and risk, not on executive authority.

Next, the story references an unspecified source that indicated that the methods used "do not work like a normal virus" - "clever" and "tenacious" is the only description provided. The story also reports "a major foreign intelligence agency has taken control of major portions of their network", referring to the oil companies. This suggests that our commercial antivirus tools may not be capable of detecting or completely removing the intruding software – it gives the term "spyware" new meaning. The lesson is that many attacks have no obvious results and are invisible to users. There is a clear need for highly trained security professionals that are constantly monitoring a broader range of IT system activity to detect and investigate anything out of the ordinary. It will be more and more difficult to balance privacy needs and security.

One pressing question is how this super spyware got into the oil companies. As usually it appears to have been simple. The story describes how spyware was released in one oil company when an executive clicked on a link in a fake email that appeared to be coming from a peer ("spear-phishing"). The lesson here is that big and bad things can happen even from simple mistakes. There are far too many opportunities for these and the only solution is severely limit access to important information, limiting not only the people but also the time that information can be accessed. Not just time of day, but also make it temporary, and under document specific access controls. This in itself is not an easy solution, if only because of the large and difficult task of classifying a large volume of documents.

There are several other good points for discussion in Mark's story, but I want to end with a problem that seems obvious. Businesses will not disclose information about cyber security incidents. In some cases, the US FBI even seems to discover the problem before the company? Since the FBI is involved, it appears that we are dependent on the FBI to investigate incidents, and disseminate lessons and actions to other businesses so that they can avoid the same problem. I am not so confident that the FBI sees this as their role, which is a problem to be sorted out – at least for further investigation.

Posted at 9:48 AM by Bob Mick | Category: Attacks | Permalink | Email this Post | Comments (0)

1/4/2010

Time to Update Your Firewall Strategy?

By Robert Mick, ARC Advisory Group

Firewalls have been the security workhorses for many years, and are still the first thing that you must put in place when securing systems, even at home. But today, firewalls are available in a wide range of forms and capabilities, making selection, implementation and management a complex undertaking. If you implemented your firewalls more than a few years ago, you may need to replace them with newer, more capable products. However, firewall technologies are still evolving and this is not an easy decision. I have been looking at emerging firewall technologies and thought I would touch on a few key areas that might motivate you to think about updating your firewall strategy in 2010.

From Protecting the Network Perimeter to Protecting the Zone Perimeter

Firewalls were initially installed at the edges of networks and this is still absolutely essential. But today, almost all business networks are complex enough that they must be broken into security zones (some call them enclaves) to accommodate different security requirements. For example a Web site exposed to the Internet must be isolated from business systems where financial information is stored. For manufacturers, systems in operations must be isolated from business systems. However, complete physical separation is no longer feasible and firewalls are necessary at the edges of these zones.

Implementing multiple security zones can be done with multiple firewalls, but some vendors now provide the capability to implement multiple zones within one device (appliance or router). You may find this cost effective and easier to manage.

From Blocking Ports to Protocol Inspection

Initially firewalls simply permitted or denied traffic based on communication protocols or ports, and in fact most firewalls intended for home still do not go beyond this. However, most modern firewalls intended for businesses offer considerably more. "Stateful" firewalls monitor the state of connections between computers and understand the protocols that flow through them. This enables the firewall to detect many abnormal situations - many attacks are not proper transactions - and discard potentially harmful communication before they enter the network. Interestingly, this approach addresses a class of vulnerabilities, some of which have not yet been developed.

As you might expect, stateful firewalls can be more complex to select, configure and maintain. Product selection becomes more complex because specific protocols are not supported equally by different vendors. Furthermore, the ability to understand protocols opens the door to many other features. These features also differ by vendor and must be matched to your specific needs, configured, and maintained as your network changes and threats evolve.

The Emerging Application Firewalls

Application firewalls go beyond basic stateful capabilities and add the ability to detect and monitor how applications communicate. Communications that are suspected as abnormal for specific applications – even though they are not wrong from a protocol perspective – can be flagged or even dropped. When combined with other capabilities such as the ability to limit access by station address or adding the capability to authenticate specific participants, application firewalls take security to a new level, closing the door to many attack methods.

Application firewalls are an important emerging technology because many new attacks have appeared at the application level. It is important to note that "Web application firewalls" are different than application firewalls. Web application firewalls are built specifically for the kind of attacks that can occur with Web applications that are exposed to the internet; application firewalls are designed for deployment inside the network perimeter as well.

But Wait! There is More!

Hopefully, you can see that firewall technology has been evolving and might justify an update to your security infrastructure. In addition to the above topics, there are several other perspectives that deserve a discussion, such as firewall packaging, how they apply to Industrial Control Systems (ICS), firewalls that come with operating systems and firewalls that come with antivirus software. Some businesses, including manufacturers, utilities and others with ICSs may need multiple types that are tuned to the needs of each security zone.

If you are using advanced firewalls in conjunction with ICS, let me know: bmick@arcweb.com

Posted at 3:23 PM by Bob Mick | Category: Firewalls | Permalink | Email this Post | Comments (0)

12/11/2009

Security Surveys Revisited

By Robert Mick, ARC Advisory Group

A few years ago ARC conducted annual cyber security web surveys, but we stopped when it became a burden for our followers. Recently, I was experimenting with something I called "30-Second Surveys" and the encouraging responses I got motivated me to take it to the next level.

Here is the concept. Rather than one comprehensive survey, I'll create a few smaller ones that might take just 1-3 minutes to complete. I will work hard to make them painless and try to hit important topics - where you need answers.

I just created one about "budgeting for security", which will help validate my market study results, and give you a metric for your budget process. You can access it from the left column on this blog site under the "Surveys" title.

The most painful part of this one is entering an email address (I need something to validate the quality of entries). I'll try to develop a scheme where you can enter a code and do not have to enter any info about your company, industries, …

In the mean time, if you are an end-user or owner-operator, I would sincerely appreciate you taking the survey and I will develop a way to publish the results frequently to all participants.

Posted at 3:30 PM by Bob Mick | Category: Surveys | Permalink | Email this Post | Comments (0)

12/6/2009

Looking for A Security Process Reference Model?

I have always been a fan of the Carnegie Mellon's Capability Maturity Model (CMM) for software engineering, but have never looked at their model for security engineering (SSE-CMM). Happily, my current search for good security process references gave me an excuse to review it. I had high hopes that its security domain material would provide a solid high level security process framework that could be adapted for Industrial Control Systems (ICS), but I was disappointed.

Specifically, the document I am talking about is The Systems Security Engineering Capability Maturity Model (Model Description Document version 3.0, http://www.sse-cmm.org/docs/ssecmmv3final.pdf).

After looking through the 326 page document, I concluded that there is very little about SSE-CMM that actually recognizes the security domain. With the exception of the identification of eleven systems security engineering process areas (see below), one could almost replace the word "security" with another domain name and the document would be equally effective. To be clear, the document is of course a good generic process assessment and improvement model. But do not go there looking for specific help with your security program.

SSE-CMM identifies eleven systems security engineering process areas (not processes), purposely listed alphabetically to "discourage any notion that the process areas are ordered by lifecycle phase or area":

PA01 Administer Security Controls
PA02 Assess Impact
PA03 Assess Security Risk
PA04 Assess Threat
PA05 Assess Vulnerability
PA06 Build Assurance Argument
PA07 Coordinate Security
PA08 Monitor Security Posture
PA09 Provide Security Input
PA10 Specify Security Needs
PA11 Verify and Validate Security

They sound like processes but they are not (and again, they were never intended to be) processes. The basic problem with using these areas as a security process reference model is that many of areas cut across multiple real cyber security related processes. For example, a security event, such as the publication of a specific vulnerability, typically triggers a process such as this, and you can see that several processes areas are touched:

Examination of the threat (PA04)
Evaluation of the vulnerability (PA05)
Assessment of the risk (PA03)
Assessment of Impact (PA02)
Coordination with vendors (PA07)
Determination of mitigation strategies (PA?)
Deploying mitigation measures (PA?)
Waiting for correction to vulnerability (PA?)
Testing correction (PA?)
Deployment of correction (PA?)
Monitoring for issues (PA08?)
Removal of mitigation measures (PA?)

The eleven process areas are detailed in section 6 of the referenced document but the details are also shallow when it comes to security content. I am still reviewing the SSE-CMM library and intended to extract the security specific concepts from the referenced document at some point. After all, it looks like there were about 90 people on the SSE-CMM team, and I am sure they had a good reason for choosing security areas instead of trying to get close to the real security processes.

Security has evolved considerably since SSE-CMM was created, and we should be able to find a more specific security process reference model. But I will have to look elsewhere. What security process reference model do you use for ICS? bmick@arcweb.com

Posted at 12:58 PM by Bob Mick | Category: Standards | Permalink | Email this Post | Comments (0)

11/29/2009

The Thin Line Between Testers and Hackers

By Robert Mick, ARC Advisory Group

Most of my cyber security work has been at the strategic and industry level, but research for ARC's "Rethinking Cyber Security" program has led me into some very interesting new areas. As noted in a posting about the NIST Smart Grid report, one of those is security testing. The more I look at security focused testing the more I believe it is essential to more secure systems and deserves considerably more attention. Having come from a software development background, I should have made the connection earlier, but like many in our industry, I have been focusing on aspects of security.

Cyber security testing is already happening in several places such as software and device development. It makes sense that there should be overall framework, reference model, strategy or something to give our diverse testing efforts structure but I have not found one. If you know of one, let me know.

Certainly one important element of any testing framework is tools and automation, and this is where security testing differs from traditional software testing. Traditional functional software testing exercises all the intended uses and capabilities of a product and usually includes a variety of stress test. In contrast, security testing must look for all the unintended capabilities and exploitable failure modes, no matter how unlikely they are to occur. These fundamental differences make traditional software test tools ineffective for many phases of security testing.

Of course, security test cases can, and should, be added to various phases of software and system component development. Existing tools may need to be extended to address some of the common failures that create vulnerabilities. But many commonly exploited vulnerabilities are introduced during system integration, configuration, maintenance, changes and updates. For example, "SQL injection vulnerabilities" often expose confidential personal data and are introduced when the application is built, not in the off-the-shelf SQL database products themselves. These application and configuration vulnerabilities dictate that ongoing system level testing is an important part of any security strategy.

System level security test tools are where things get very interesting because the good guy's test tools have much in common with the bad guys exploit tools. A tool built to find the SQL injection vulnerabilities mentioned above can be used by both sides. They are readily available to anyone. Many are free and even a high cost is only a deterrent for the hobby hackers. This where the line between systems testers (or admins) and hackers gets very thin. The tools, skills and techniques are the similar, but the motivations and end results are different.

In spite of the similarities, there the challenges of the good guys vs. the bad guys differ significantly, and these differences must drive our efforts. Hackers are not testers! Testers must be much more disciplined. The tester's goal is to find all vulnerabilities in a majority of our systems while the hacker only needs to find one. This suggests that if they use the same techniques, we will need a lot more testers than hackers to be effective. Consequently, security testing must be comprehensive, repeatable and automated as much as possible. Based on my research so far, I don't think our testing strategies, frameworks and tools are up to the challenge, and we have a lot of work to do in each of these areas. However, I certainly need to know a lot more about security test tools.

I hope to compile a list of good system level test tools, mainly to get a better perspective of what actually needs to be done. If you are using tools routinely to make your systems more secure, please let me know what you are using. I will share what I learn in some way (anonymously of course): bmick@arcweb.com .

Posted at 11:46 AM by Bob Mick | Category: Testing | Permalink | Email this Post | Comments (0)

11/16/2009

Cyber War Hits the News

By Robert Mick, ARC Advisory Group

Last week two cyber security news events stood out and are worth mentioning here in case you missed them. A little over a week ago, the CBS program "60 Minutes" showed a TV segment titled "Cyber War: Sabotaging the System". It likely has nothing new for readers of this blog, but the general population found it a bit scary. Many people still think that the scenarios addressed by 60 Minutes are not really possible. Some will ask: If we are so unprepared and vulnerable, why have we not had frequent disruptions of our power and banking systems? Are the bad guys just waiting for the right moment? Have they not reached the level of control needed for massive disruption? Are they busy with other activities that are more beneficial personally? Do they fear physical retaliation? Or, are our systems really better prepared than 60 Minutes portrayed?

My sense is that the answer to all these questions is "yes". In my personal opinion, 60 Minutes presented largely one side of the story, was overly dramatic, and weak on completeness. But the facts reported in the segment are that there have been successful penetrations of some of our power systems, banks have been robbed, and even our defense systems have been penetrated and raided for information. I say GOOD for 60 Minutes for reminding us and bringing it to the attention of a lot more people.

The second event was the publication of an article by Shane Harris titled, "The Cyber War Plan," appearing last Saturday. This piece describes how a new battlefield has been emerging in cyber space. It is an interesting read because it demonstrates links between military and private sectors. There is only one battlefield, the Internet, and our businesses and homes are on it. We are not only likely to be impacted, but our systems are also likely to be participants. This linkage is reason enough for us to pay careful attention to the focus and pace of cyber security progress in the private sector, relative to the demands of cyber war.

Of course, this linkage is not new, but the cyber war activity is picking up, upsetting the current balance. As a consequence, it guarantees continued escalation in sophistication of attacks and strategies. It also means less tolerance from the government and political arenas of the slow pace in the private sector. I believe that to rebalance, investment in cyber security by the commercial sector must increase. I also believe that cyber security organization and strategy within most businesses will need to mature and grow.

Cyber incidents, and especially cyber war, have the necessary ingredients to become very popular news topics, especially with the Internet driving change in the news industry itself. This attention and education of the general public are just what we need to drive positive change. Unfortunately, cyber security is also highly technical, making it prone to misunderstanding. If security follows the same path as public and government reactions to financial business issues, we are headed for stringent security management and reporting requirements. The days of keeping your security issues secret will be over. Better make sure your security practices are in order.

Posted at 4:08 PM by Bob Mick | Category: In the News | Permalink | Email this Post | Comments (0)

RSS Feed

1 - 10

‭(Hidden)‬ Admin Links

Short Surveys

2/19/2010

2/18/2010

The Energy was One of the First

The Chemical Sector

Observations

Actions

Using Third Party Security Services for ICS

ICS Device Certification and Testing

Panel Discussion

Observations

Actions

2/17/2010

Rethinking ICS Cyber Security Does Not Mean Starting Over

Workshop Strategy

Workshop Observations

Actions

1/27/2010

1/4/2010

From Protecting the Network Perimeter to Protecting the Zone Perimeter

From Blocking Ports to Protocol Inspection

The Emerging Application Firewalls

But Wait! There is More!

12/11/2009

12/6/2009

11/29/2009

11/16/2009

ARC Cyber Security Blog

Current Topics and Resources

Finding Operations Security Info