Tuesday, 21 September 2010

The Real Costs of Security

A must-read is “Cyber Threats to National Security: Countering Challenges to the Global Supply Chain,” which CACI published last July. Although it’s supposed to be just a “summary of the personal remarks made by participants at the March 2, 2010 symposium” that was co-sponsored by CACI and the U.S. Naval Institute, a very fine and anonymous editor has turned those remarks into a well-crafted and readable white paper.

 

One clear message of the report is that both government and industry continue to take a “penny-wise, pound-foolish” attitude toward security because the economic incentives and disincentives tend to push them in that direction. The report observes that:

 

…that there are very few individuals or companies that focus on the global end-to-end requirements or security of the supply chain. Components of all scales are usually considered fungible and, consequently, most suppliers are not paid for ensuring all aspects of quality and security… That degree of oversight is most often neither contractually nor culturally their job or their responsibility.

 

The cultural factors involved with security are of particular interest to me but I’ll focus on that in future blog entries. I’d like to highlight here the parts of the report which point to the inability of the market to deal with security. I’ve bolded a couple of points below should be discussed in greater depth – and urgency – by government and industry.

 

To date, market forces have not favored products with cybersecurity capabilities that make systems secure at the level required for national or economic security. Companies, and by extension broader society, still view cybersecurity as a revenue drain or an add-on, not as an imperative. Consequently, adequately robust cybersecurity products have not benefited from the economies of scale of the global mass market.

 

The result has been a “market failure” to the extent that the U.S. can’t afford the security necessary to survive in a system it created. …Since competition for information technology systems is furious and capability is often considered over security, industry continues to develop insecure systems. Purchasers continue to select “competitively priced” products with insecurity engineered in even while the U.S. becomes increasingly less able to afford them from a security standpoint.

 

As I said in an earlier blog entry, you “can pay now or you can pay later.” My first choice would always be that the market can come up with the solutions. But, if in an area of such importance to U.S. national security, the market is not doing its job, perhaps some outside stimulus is needed. Hopefully, that stimulus won’t come in the form of an attack or breach which takes down major critical infrastructure or shuts down a critical government agency or steals millions of Social Security records.

Technorati Tags:

Posted by rroy at 7:25 AM in Fortify

The Real Costs of Security

A must-read is “Cyber Threats to National Security: Countering Challenges to the Global Supply Chain,” which CACI published last July. Although it’s supposed to be just a “summary of the personal remarks made by participants at the March 2, 2010 symposium” that was co-sponsored by CACI and the U.S. Naval Institute, a very fine and anonymous editor has turned those remarks into a well-crafted and readable white paper.

 

One clear message of the report is that both government and industry continue to take a “penny-wise, pound-foolish” attitude toward security because the economic incentives and disincentives tend to push them in that direction. The report observes that:

 

…that there are very few individuals or companies that focus on the global end-to-end requirements or security of the supply chain. Components of all scales are usually considered fungible and, consequently, most suppliers are not paid for ensuring all aspects of quality and security… That degree of oversight is most often neither contractually nor culturally their job or their responsibility.

 

The cultural factors involved with security are of particular interest to me but I’ll focus on that in future blog entries. I’d like to highlight here the parts of the report which point to the inability of the market to deal with security. I’ve bolded a couple of points below should be discussed in greater depth – and urgency – by government and industry.

 

To date, market forces have not favored products with cybersecurity capabilities that make systems secure at the level required for national or economic security. Companies, and by extension broader society, still view cybersecurity as a revenue drain or an add-on, not as an imperative. Consequently, adequately robust cybersecurity products have not benefited from the economies of scale of the global mass market.

 

The result has been a “market failure” to the extent that the U.S. can’t afford the security necessary to survive in a system it created. …Since competition for information technology systems is furious and capability is often considered over security, industry continues to develop insecure systems. Purchasers continue to select “competitively priced” products with insecurity engineered in even while the U.S. becomes increasingly less able to afford them from a security standpoint.

 

As I said in an earlier blog entry, you “can pay now or you can pay later.” My first choice would always be that the market can come up with the solutions. But, if in an area of such importance to U.S. national security, the market is not doing its job, perhaps some outside stimulus is needed. Hopefully, that stimulus won’t come in the form of an attack or breach which takes down major critical infrastructure or shuts down a critical government agency or steals millions of Social Security records.

Technorati Tags:

Posted by rroy at 7:23 AM in Fortify

Wednesday, 4 August 2010

Bananas and Innovation in Gov't

Five monkeys were placed in a cage in which a banana was suspended from the ceiling with a stepladder positioned underneath it. As expected, a monkey went to the ladder to climb up for the banana, but as soon as he touched the ladder he set off a spray that soaked all the other monkeys with freezing water. Each monkey also tried to reach the banana with the same result. It didn't take long for the monkeys to learn that the best way to stay dry and warm was to prevent any monkey from attempting to reach the banana.

The next stage of the experiment was to remove the spray from the cage and to replace one of the monkeys with a new one. Of course, the new monkey saw the banana and went over to climb the ladder. To his horror, the other monkeys attacked him. After another attempt, he learned that if he touched the ladder, he would be assaulted.

Next, another of the original five was replaced with a new monkey. The newcomer went to the ladder and was attacked. The previous newcomer joined in the attack with enthusiasm!
Then, a third monkey was replaced with a new one and then a fourth. Every time a newcomer approached the ladder, he was attacked. Most of the monkeys beating him had no idea why they were not allowed to climb the ladder or why they were joining in the beating of the newest monkey.

After replacing the fifth monkey, none of the monkeys had ever been sprayed with water. Still, no monkey ever approached the ladder. Why not? Because as far as they knew it was the way it had always been done around here.

This story usually ends with the moral, “And that’s how company (or agency) policy begins.”

I was reminded of this story at a Capitol Hill hearing last week held by the House Armed Services Committee Terrorism and Unconventional Threats and Capabilities Subcommittee. (Fortify’s founder and CTO, Roger Thornton was one of the witnesses.) The subject was harnessing small businesses innovation for national security cyber needs, and one of the issues discussed was the systemic barriers that small businesses face when entering the government cyber security marketplace.

Small businesses represent 99.7 percent of all employer firms in the United States, employ half of all private sector employees, and have generated 60–80 percent of net new jobs annually over the last decade. American small businesses are also the engine of innovation for the nation. Don’t take my word for it — I’m quoting the chairperson of the Terrorism and Unconventional Threats and Capabilities Subcommittee, Rep. Loretta Sanchez, at the hearing.

But small businesses — and the innovative solutions they can offer for complex problems in government, including cyber security, face a federal procurement workforce that has been conditioned — like the monkeys — to avoid risk at their peril. And that means going with the same ol’ ways of doing things and the same ol’ people who do them — because it’s safe. And can you blame them?

The federal acquisition workforce is made up of very hardworking and talented people — but they’ve been trained and conditioned to set up “systemic barriers” to innovation — because it’s the safe and logical thing to do — which means that small businesses that bring innovative solutions and innovative ways of thinking often face steep barriers to entry or winning contracts. Is there perhaps something Congress could do about that?

 

Posted by rroy at 10:44 AM in Fortify

Tuesday, 29 June 2010

Software Assurance Journey Begins with the First LOC

According to (ISC)2’s recently published report, “The 2010 State of Cybersecurity from the Federal CISO's Perspective,” federal CISOs ranked exploitable software vulnerabilities (27%), poorly trained users and/or insider threats (24%), and foreign nation states (21%) as by far the most severe threats their agencies faced.

On the other hand, when the CISOs were asked to be the White House Cybersecurity Coordinator for a day and make recommendations for what would be their highest priorities, increased agency funding (of course) and effective deployment of TIC/Einstein to protect agency networks tied at 21%, while expanding cybersecurity coordination to states and the private sector was ranked second at 18%. Strange to say, addressing software vulnerabilities did not make the list, although it might have been included in “other” (7%).

First of all, we understand the “Coordinator for a Day” list of priorities, which also included increasing public awareness (12%), developing a national cyber incident response capability (9%), and developing a national cyber training institute (9%), and strengthening international collaboration and deterrence strategy (3%). Most of the list focuses on long-term initiatives which the White House Cybersecurity Coordinator is uniquely positioned to deal with.

Based on our experience, we would suggest that the reason — or at least a significant reason —why addressing software vulnerabilities did not make the list even though it was ranked by the same CISOs as the more severe threat, is because addressing the issue of software security assurance too often turns into an “all or nothing” discussion. Because the job appears so daunting (there are, after all, thousands of millions of lines of code out there in government networks and applications), it also appears to be unmanageable. Better to concentrate on strengthening the perimeter and improving firewalls anti-virus protection and intrusion prevention systems and getting fancier security information and event management (SIEM) dashboards – all worthy endeavors, but which aren’t very useful for repairing vulnerabilities built into the software.

Doing something about those “exploitable software vulnerabilities” is not an “all or nothing” proposition. Like many difficult things, it is a long-term journey that has manageable first steps.
Consider:  less than 10% of the federal IT budget is spent on security, and nearly 100% of that is focused on the network. Yet… attacks outside and inside the perimeter are changing every day and growing exponentially.  The Web Application Firewall/Anti-Virus/Anti-Malware (WAF/AV/AM) attack-based solutions are doing everything they can to pump out signatures, but the attackers using "force multipliers" like botnets numbering in the millions of infected systems worldwide simply outnumber the ability of the "good guys" to keep up.

So, you can shut down Port 80 access — voila!  Problem solved, except that you just stopped business altogether.

Or, you can spend some time and money on fixing the vulnerabilities that all of these attacks are designed to exploit. As a benefit, it can mean reducing the resources you spend on perimeter defense. And, by the way, you’ve increased the effectiveness of those perimeter defenses.

How do we begin this journey? 

* Determine and categorize your application risk
* Assess your risk posture 
* Calculate ROI
* Triage remediation of riskiest issues

Now let’s start doing something substantive about reducing and repairing those vulnerabilities.
-RR
Posted by rroy at 3:00 PM in Fortify

Software Assurance Journey Begins with the First LOC

According to (ISC)2’s recently published report, “The 2010 State of Cybersecurity from the Federal CISO's Perspective,” federal CISOs ranked exploitable software vulnerabilities (27%), poorly trained users and/or insider threats (24%), and foreign nation states (21%) as by far the most severe threats their agencies faced.

On the other hand, when the CISOs were asked to be the White House Cybersecurity Coordinator for a day and make recommendations for what would be their highest priorities, increased agency funding (of course) and effective deployment of TIC/Einstein to protect agency networks tied at 21%, while expanding cybersecurity coordination to states and the private sector was ranked second at 18%. Strange to say, addressing software vulnerabilities did not make the list, although it might have been included in “other” (7%).

First of all, we understand the “Coordinator for a Day” list of priorities, which also included increasing public awareness (12%), developing a national cyber incident response capability (9%), and developing a national cyber training institute (9%), and strengthening international collaboration and deterrence strategy (3%). Most of the list focuses on long-term initiatives which the White House Cybersecurity Coordinator is uniquely positioned to deal with.

Based on our experience, we would suggest that the reason — or at least a significant reason —why addressing software vulnerabilities did not make the list even though it was ranked by the same CISOs as the more severe threat, is because addressing the issue of software security assurance too often turns into an “all or nothing” discussion. Because the job appears so daunting (there are, after all, thousands of millions of lines of code out there in government networks and applications), it also appears to be unmanageable. Better to concentrate on strengthening the perimeter and improving firewalls anti-virus protection and intrusion prevention systems and getting fancier security information and event management (SIEM) dashboards – all worthy endeavors, but which aren’t very useful for repairing vulnerabilities built into the software.

Doing something about those “exploitable software vulnerabilities” is not an “all or nothing” proposition. Like many difficult things, it is a long-term journey that has manageable first steps.
Consider:  less than 10% of the federal IT budget is spent on security, and nearly 100% of that is focused on the network. Yet… attacks outside and inside the perimeter are changing every day and growing exponentially.  The Web Application Firewall/Anti-Virus/Anti-Malware (WAF/AV/AM) attack-based solutions are doing everything they can to pump out signatures, but the attackers using "force multipliers" like botnets numbering in the millions of infected systems worldwide simply outnumber the ability of the "good guys" to keep up.

So, you can shut down Port 80 access — voila!  Problem solved, except that you just stopped business altogether.

Or, you can spend some time and money on fixing the vulnerabilities that all of these attacks are designed to exploit. As a benefit, it can mean reducing the resources you spend on perimeter defense. And, by the way, you’ve increased the effectiveness of those perimeter defenses.

How do we begin this journey? 

* Determine and categorize your application risk
* Assess your risk posture 
* Calculate ROI
* Triage remediation of riskiest issues

Now let’s start doing something substantive about reducing and repairing those vulnerabilities.
-RR
Posted by rroy at 2:57 PM in Fortify

Friday, 21 May 2010

To Cloud or Not to Cloud

Last week (May 13th) federal CIO Vivek Kundra again extolled the benefits of moving to the cloud when he noted that the Recovery Accountability and Transparency Board was moving Recovery.com to the cloud. In his blog, Vivek wrote:

"By using cloud services, the Federal Government will gain access to powerful technology resources faster and at lower costs. This frees us to focus on mission-critical tasks instead of purchasing, configuring, and maintaining redundant infrastructure."

We absolutely share Vivek’s enthusiasm for the potential benefits of moving to the cloud, particularly when it comes to the potential for reducing costs and increasing agility to adapt and incorporate new technologies. But… and it’s a big “but” – we also have to raise our hand and point out that “potential” can also work in opposite and harmful directions.

Just as technology can be an enabler of good things it can also be an enabler of bad things with harmful consequences – and at much faster speeds than in the past. (Ask anyone who accidentally hit “Reply to All” when they meant to send a very private e-mail to only one person.) Likewise, moving to the cloud without careful precautions and preparations can also be an enabler of harmful consequences that could easily cause damage far exceeding the reduced costs and benefits.

Your systems and applications are probably already vulnerable to external and internal exploits because of software vulnerabilities. Moving to the cloud has the potential to increase those vulnerabilities and their associated dangers because you open yourself up to the vulnerabilities in other entities on the same cloud. Moreover, by giving up control of your systems, processes and security to the cloud you can make yourself more vulnerable because you don’t know what your host is doing – or not doing.

One only has to look at the hack earlier this month of four Treasury Department Bureau of Engraving and Printing websites that had been moved to the cloud. Hackers exploited a number of common software bugs in the host’s servers and injected malware into the websites, which then redirected visitors to a Ukrainian website that then launched Web-based attacks.

To unlock the full potential of the cloud, both cloud consumers and providers must address the number one concern related to moving business and operations to the cloud: security. And given that an estimated 75% of attacks are at the application layer, software security assurance needs to be the top security priority.

By all means, give serious consideration to moving your operations to the cloud. But as you do so, cloud consumers must ensure that their software code is ready for such a move, particularly in the areas of communications security, network infrastructure and data protection. On the other hand, cloud providers must ensure that the software at the heart of their infrastructure is secure – and that their customers are not introducing bad code into their environment. And cloud consumers must make sure that their hosts are doing just that.

The cloud offers great potential for both good and evil. Ensure the software on both ends and good will triumph – and provide an excellent return on investment as well.

-RR
Posted by rroy at 1:54 PM in Fortify

Monday, 10 May 2010

What keeps you up at night?

When asked by TheStreet.com, "What keeps you up at night?", Aneesh Chopra, the federal chief technology officer (CTO) of the U.S., replied, "I am not sure that it will be a denial of service attack, as much as it will be sloppy software implementations that have left holes for hacking."

As the federal chief technology officer of Fortify Software, which focuses on software security assurance, I wouldn't call it "sloppy software implementation" but rather "inadvertent" code vulnerabilities. I say "inadvertent" because most software developers and engineers do not have security training and instead focus on features and performance. It might be sloppy if their training and experience did include security, but because security is not embedded in the lifecycle of software development and implementation, we should not place blame or fault on them.

Before I go much further, let me address the question: why this blog? Do we really need another blog about cybersecurity? It may be self-serving but I think the answer is yes, in large part because software security assurance -the sum total of the people, process and technologies that can be brought to bear on the problem of software risk - is critically important to all businesses, but still not well understood or common practice.

As I write these words, an oil spill 50 miles off the Louisiana shore is threatening the coastal environment - with far-reaching impacts on people and businesses. What caused this crisis was "inadvertent", but it is causing billions of dollars of damage to sensitive marine life and the businesses and people that depend on this ecosystem for their livelihoods. A piece of malware inserted by a hacker or a "hacktivist" into a system that has a "built-in"€vulnerability in a software application could, and sometimes does, have a similar impact. We need to bring as many experiences and insights to the software security discussion as possible in order to reduce and ultimately eliminate this risk.

I look forward to blogging on topics and trends related to software security, especially in the federal arena, and welcome your thoughts, comments and ideas. With any luck, software and application security will soon be such an integral part of how all organizations practice good security, Aneesh Chopra will stop losing sleep and I will lose my job as a blogger.

-RR
Posted by rroy at 11:20 AM in Fortify