Home Information Sharing & Analysis Prevention & Protection Preparedness & Response Research Commerce & Trade Travel Security Immigration
About the Department Open for Business Press Room
Current National Threat Level is elevated

The threat level in the airline sector is High or Orange. Read more.

Homeland Security 5 Year Anniversary 2003 - 2008, One Team, One Mission Securing the Homeland

Remarks by Assistant Secretary Gregory Garcia at the CA World Conference

Release Date: April 24, 2007

Las Vegas, Nevada
CA World Conference 
(Remarks as prepared)

Thank you. I am delighted to be here with you today. I would like to thank CA World for inviting me to participate in this conference. Although I wonder if inviting me to Las Vegas to speak is some veiled signal that you’re throwing the dice -- taking a gamble -- by having someone from Washington come to speak to you. I know you’re thinking that all the hot air in Washington isn’t just due to the weather. Nevertheless, I’m here and I have a few things to say to you today.

I want to say before I get started that CA has truly been an influential and active supporter and industry leader of our cyber security initiatives throughout the existence of the Department of Homeland Security, and I am grateful to John Swainson, Ron Moritz and John Sabo for their leadership and for doing the company’s part to raise awareness about our national cyber security challenge through forums like this.

In September of last year, I was appointed by the president to head the Homeland Security Department’s Office of Cyber Security and Communications, the first assistant secretary with that considerable responsibility.

This office was established by Secretary Chertoff with this mission:  to assure the security, resiliency, and reliability of the nation’s cyber and communications infrastructures and to do it in collaboration with government and private sector stakeholders.

The “cyber” and the “communications” in my title are put together under one roof to reflect the interdependency and convergence that has taken place between our IT and communications networks. In a few years communications will have converged into one interdependent digital IP network. This of course simplifies and enhances the way organizations communicate information, but also exposes us to new network security challenges. When I think of cyber security, I worry about how cyber attacks can disrupt our IP-based communications. When I think of communications disruptions, I worry about the effect of mass disruptions on our cyber infrastructure. It’s a converged environment and a converged security mission.

Let me give you a brief overview of how we’re organized to meet the challenges of this converged environment. The office is comprised of three components that are dedicated to furthering this mission.

The National Cyber Security Division which fosters a public-private partnership for cyber security awareness, risk management and mitigation; and information sharing and incident response.

The National Communications System which ensures that our government and our nation have access to communications in times of national emergency.

And the newly established Office of Emergency Communications which sets national policy, standards, practices and technical assistance for emergency, interoperable and operable communications for federal, state and local first responders.

Each of these components works together to foster public, private, and international partnerships and to enhance the preparedness and resiliency of our nation’s it and communications infrastructures.

Now, I have three overarching strategic priorities for my office:

First, Prepare and Deter against the potential for catastrophic incidents;

Second, Respond, by operating a coordinated national system for responding to major cyber and communications disruptions;

And third, Build Awareness for a well informed public – at home and in the enterprise – who understand the shared responsibility we all have to protect our it and communications networks.

Transforming these broad strategic priorities into actual results is a complex undertaking, given how the cyber and communications risks and vulnerabilities we face come in many forms and are constantly evolving.

So what does this mean for this audience? I can tell you I’ve come to the right place to say what this means. From what I see, this gathering represents a powerful intersection of the architects, the managers and the users of the information society. Here are the software developers – and -- the companies and enterprises that use software systems to run companies, manufacture and sell goods, process financial transactions, and provide vital services. And when it comes to software security and its implementation, that intersection – that shared responsibility – between developer and customer is – or should be – the catalyst for improvements in our national cyber security posture.

But I don’t think we hear enough about this relationship. Sometimes, in fact, when we talk about how responsibility for cyber security should be shared by vendors and users, the discussion has been characterized perhaps more often by tension, than by traction.

I can tell you I’ve participated in many a meeting where the discussion goes something like this: “you know, if software weren’t so buggy and full of vulnerabilities, we wouldn’t have so many cyber attacks.”

And in reply: “look, we could make software more secure, but the customers don’t want to pay for it. And even if they did, they don’t put good security practices in place and train their people not to make user errors.”  

Might that sound familiar? To me it does, but it doesn’t sound helpful.

Perhaps I oversimplify that conversation, but the point needs to be made: in the past there has been somewhat of a commitment gap – a gap in acknowledging that security is a shared responsibility; a gap in investing in secure software development; and a gap in implementing enterprise security that would meet that responsibility head on.

Let me also be clear: I do see that that gap has been closing, and we should be encouraged. There has been some notable progress in our security investment and awareness, maybe some companies and sectors more than others, but in my view it’s not yet enough on a national scale. What we at DHS call a national culture of security. Candidly, I’m not so sure we’re keeping up with the progress that our adversaries have been making to exploit that commitment gap.

So today I want to be the guy in the middle –the honest broker, if you will, to bring everyone to the middle – to talk about how the software industry might grab this security problem by the throat, and how those in industry and government who are using these software systems might grab this security problem by the ankles, and together wrestle it down. As I go through this, I also want to offer you a couple of examples of the intersection between software development and software implementation that should illustrate why we have to work closely together on this.

Let’s start with a statistic: Carnegie Mellon estimates that up to 90 percent of reported security incidents result from the exploitation of defects in software design or code. This is an alarming statistic. I’m sure some can refute it to some degree, but it cannot be ignored. Software is ubiquitous but flaws need not be.

But I think we all know just as well that security incidents are also caused by users not calibrating their configurations to their security requirements. They’re also caused by insider problems stemming from poor employee training, inconsistent access control policy, and fragmented security implementation and patch management practices. It isn’t just the technology that has responsibility to secure our networks; it’s the people and the processes too.

Okay, now I’ve teed it up. Let me give a couple examples of the types of vulnerabilities this commitment gap is creating for us that concern me.

These examples really speak to both the software and its implementation. I’m speaking of global supply chain vulnerabilities and control systems vulnerabilities.

First, supply chains. The information and communications technology supply chain—including design, sourcing, manufacturing, shipping, and service—has become global through foreign operations of us-based companies, offshore outsourcing of products and services, and international mergers and acquisitions.

Globalization leverages competitive efficiencies and economies of scale. It’s the natural order of your business. But globalization has also introduced more complex threats and serious vulnerabilities in software and hardware products and services.

How so? Technologically sophisticated adversaries are increasingly able to infiltrate and corrupt product design and functionality at any point along the supply chain. These products and services are often integrated in government and private-sector network systems that support—and are interconnected with—national security systems, financial transactions, electric power, energy distribution, transportation, and industrial processes.

Consequently, government and private-sector stewards of our critical networks are simply less able to rely unconditionally on the integrity of hardware and software products and services, whether or not they are provisioned by us-based manufacturers and network operators. Often, it’s an insider problem; the wrong person was hired. But it’s also a process discipline challenge. This is a software development issue.

The second issue: control systems. We’re talking about water purification, chemical manufacturing, electrical grids, rail switching, many others. These are control systems that regulate processes. They are able to regulate processes because they in turn are controlled by software. Buggy software? Maybe, but maybe not.

Of more interest is the fact that these systems increasingly are connected to IP networks that are in turn connected to the business networks that can be accessible to the outside – accessible to those who would corrupt or sabotage these systems through cyber attack.

There may be cost effective, productivity reasons for interconnecting these networks, but security isn’t one of them. Security is in fact jeopardized when the implementation of a control system allows the exposure of critical processes – processes that affect public safety and health, or economic and national security – to malicious cyber exploitation. This is an implementation issue.

So where do we go from here?

On the control systems issue, my office has been conducting a process control systems forum that works with other federal agencies and the private sector to identify and mitigate vulnerabilities where our software and physical infrastructures intersect. This forum engages partners in training and awareness activities, self assessment tools, and best practices. And we’re continually looking to expand private sector involvement in this work, as well as to other government agencies – federal, state and local.

On software assurance, CS&C has for the past couple of years hosted a software assurance forum in which we partner with industry, academia, and government to examine all aspects of software development lifecycle.

By that I mean: people—training and educating developers and users; processes—identifying best practices and practical guidelines for the development of secure software; technology—analyzing tools for evaluating software vulnerabilities and quality; and acquisition—encouraging software security improvements through acquisition and outsourcing specifications and guidelines.

But we’ve heard from some of our colleagues in the industry that DHS ought to supplement industry efforts where there is a gap, but that we’re not the teachers. That industry has the real software development expertise. That DHS is best at coordinating. That the software assurance forum has been useful in raising awareness, but perhaps doesn’t fully apply to the broadest cross-section of the software development community.

Well, okay, it’s good work we’ve done in the software assurance forum, but I’m willing to take the software industry up on your offer that you might have the better solution.

So here’s my proposal to you: take a shot at such a process; build upon what we’ve started and what some of you have participated in. You are the experts. I have said since I came on board, and indeed, since I was with industry, that here is an opportunity for the software sector to take leadership, pull together, and consider the range of practices and controls for secure software development – including secure supply chain management – that you all can collaboratively design, independently implement, and collectively be held accountable for. In so doing you can silence the critics and strengthen customer confidence.

What might such practices encompass? If you’ll indulge me, let me turn back the pages to 2004 when recommendations were proposed by a task force of the national cyber security partnership. It was about security across the software development lifecycle. This group was composed of industry, government and academic representatives, and was co-chaired, incidentally, by ca and Microsoft. They developed a number of very thoughtful recommendations, which I’m afraid at that time did not get the full level of attention at DHS that they deserved.

Let me share with you just a few of their recommendations, which I think could re-start a conversation toward a more organized industry effort to gain consensus around secure software development guidance. The goal is a set of practices that are practical, adaptable, measurable, and repeatable, and which will get us to a higher level of security and confidence in the marketplace. So do this:

  • Adopt software development processes that can measurably reduce software specification, design, implementation and security defects.
  • Test and measure these development practices and publish results.
  • Use DHS – our US-CERT – to help measure the effectiveness of practices that reduce software security vulnerabilities.
  • Establish a security validation program to evaluate different development practices.
  • Certify those processes, and let’s work with academia to build them into curricula.
  • Make the security of a developer’s software code a job performance factor.

These are just a few of your ideas. They’re solid, and they should be put to work.

Now, to those of you in the customer community – the users of software and the managers of some of our nation’s critical infrastructures, let me offer this to you: presented with what I just described, you are likely to see improvements in your enterprise security, and in your business process management. But there’s a catch, you’ll have to pay for it. Security doesn’t always come cheap, but vulnerabilities do.

And then you need to understand your risk profile, configure your systems properly, maintain the software that you install and apply patches in a timely manner.

Invest in the time, personnel, and resources for the fundamental building blocks of security throughout your enterprise. I think we might be surprised just how many organizations, whether government or private sector, have not invested in these first, basic steps:

  • Perform an asset inventory and vulnerability assessment of your networks
  • Establish and implement a security policy according to your risk profile that mitigates vulnerabilities and minimizes risk
  • Invest in and upgrade technology solutions, and, as a customer, demand secure systems from your suppliers
  • Ensure that employees up and down the management chain are given security training and are not permitted to engage in risky online behavior
  • Continuously test and audit your systems for compliance with your security policy and address those areas that need fixing.

These first steps will go a long way towards securing your enterprise, protecting your customers and suppliers, and ensuring the continuity and security of our nation’s critical infrastructures.

And on a broader, national policy level, I would like to urge every organization in this room to consider participating in the work that DHS has ongoing with private sector partner organizations.

To be specific, we have been working with the private sector in a national risk assessment strategy, and a national incident response capability.

On risk assessment, we have over the past year worked closely with key industry organizations to plan out how we will evaluate the vulnerabilities in our critical infrastructures, and determine where to commit the most resources to mitigate vulnerabilities posing the greatest potential consequences.

It is called the national infrastructure protection plan, and each critical sector -- it and communications, for example –developed with us the component sector specific plans. To do this, the critical infrastructure sectors organized their own sector coordinating council which are recognized partners with DHS in this process.

Similarly, many industry sectors have organized watch and warning, and incident response structures called ISACs – or information sharing and analysis centers. Two  key components of my organization – the us computer emergency readiness team and the national coordinating center for telecommunications (or NCC) -- serve as the focal points for government-industry information sharing and response related to harmful activity on our cyber and communications networks. We are particularly well partnered with the IT and Communications ISACs and are strengthening those relationships even more.

But there are many other ISACs - for financial services, electricity, water, transportation, nuclear, oil and gas, and others, that monitor their cyber and communications networks for malicious activity, and we intend to build our partnerships with them to a greater degree.

The fact is, since we are all interconnected across commercial, academic, non-profit and government networks, my organization needs to partner with operational leads among all these stakeholders in order for us to coordinate a truly national, synchronized response when a major cyber attack or communications disruption occurs. This is what is expected of us. This is what is expected of you – the owners and operators of those infrastructures.

These are some of our efforts which we are undertaking to improve our preparedness, deterrence and response capabilities, but we are not working alone. All of our efforts are built on a foundation of collaboration with our public and private sector partners.

So, here’s my final ask:  to tie together our operational and preparedness responsibilities, to leverage the relationship between software vendors and users, I strongly encourage any company that develops software, that operates a network, that manages proprietary and business sensitive information, that connects to the public networks, to join and participate in these sector coordinating councils and these ISACs, and partner with DHS to beat back the vulnerabilities afflicting our security posture. We need to become better organized than our adversaries.

Join with your industry colleagues and homeland security to secure our nation’s critical infrastructures that we all rely on. And, recognize the shared responsibility that we all have to protect our part of the nation’s networks – our nervous system.

I thank you all for giving me the opportunity to be with you this afternoon. I look forward to continuing to build partnerships with industry and expanding on our progress for the future.

# # #

This page was last reviewed/modified on April 24, 2007.