Risk

1/22/2015
10:30 AM
Jeff Williams
Jeff Williams
Commentary
Connect Directly
Twitter
LinkedIn
Google+
RSS
E-Mail vvv
100%
0%

What Government Can (And Cant) Do About Cybersecurity

In his 2015 State of the Union address, President Obama introduced a number of interesting, if not terribly novel, proposals. Here are six that will have minimal impact.

People are calling 2014 the “Year of the Breach.” President Obama even focused on “cybersecurity” during his 2015 State of the Union address. I’m thrilled that security seems to have finally broken into the public consciousness. It’s a complex problem that requires an international effort, cooperation between public and private sectors, and careful consideration of the best path forward.

The mess we're in
I’ve written before about the staggering complexity of application security in the modern enterprise. So it’s not too surprising that the level of insecurity has grown over the past 20 years due to automation’s breakneck speed. The infographic below gives a sense of just how large and complex our codebases are. But like other extremely complex issues, such as healthcare, climate change and education, government intervention is a delicate matter that may do more harm than good.

Click on this  link for an interactive view of the Word Cloud by David McCandless.
Click on this link for an interactive view of the Word Cloud by David McCandless.

The commercial sector produces the vast majority of the world’s software. But this market is failing to encourage the development of secure code. Why? Because for the most part, software is a black box. When you buy a car, you can have a mechanic check it out. But software is so complex that it can take months or years to determine whether it’s secure or not. Software is a “market for lemons” where nobody can get paid a fair market price for secure code. So our software ends up stunningly insecure.

I’m not trying to blame the victim here. Malicious attackers are the cause of breaches and we should do what we can to catch them. But given the inherent anonymity of the Internet, the “attribution problem” means that hackers are going to be part of our world for a very long time. This means we’re going to have to do more to protect ourselves.

Proposed government interventions
In his 2015 State of the Union address, President Obama introduced a number of interesting, if not terribly novel, proposals. Let’s quickly review a few of these ideas.

  1. Establish Federal breach notification legislation to unify the complex patchwork of state laws. This is a great idea in principle, although there will certainly be arguments about the details. For example, the 30-day limit is too long for consumers whose credit card number was stolen, yet too short for companies to ensure their systems are clean. I’d like to see this legislation expanded to cover all breaches, not just those that involve a privacy leak. If you’ve been hacked, even if no privacy breach occurred, your customers have a right to know the details.
  2. Expand information sharing with DHS through the ISACs. President Obama said, “we are making sure our government integrates intelligence to combat cyber threats, just as we have done to combat terrorism.” I’m not convinced that the techniques used to combat terrorists will work on hackers. While information sharing is important, it must be done carefully to protect victims of data breaches from further violation.
  3. Allow prosecutors to pursue anyone related to a hacking incident under Federal RICO statute. Given the difficulty of accurately identifying suspects, gathering evidence, and proving relationships in cyberspace, this approach seems ripe for abuse. There’s nothing wrong with aggressively pursuing cyber criminals, but we can’t forget about due process. How easy would it be to frame someone as a hacker if all that is required is a loose association? What if I friend the wrong person on Facebook or LinkedIn?
  4. Radical expansion of the CFAA. The Computer Fraud and Abuse Act is the federal anti-hacking law. Obama’s proposal expands the definition of unauthorized to include any time a user accesses information “for a purpose that the accesser knows is not authorized by the computer owner.” Basically if you know you’re hacking, then you’re guilty of a felony. This subjective standard does nothing to clarify what behavior is allowed under the statute and will lead to messy court cases and bad law.
  5. Even more CFAA expansion. Further, the proposal criminalizes your security tools if you know they could be used for illegal purposes. Another subjective standard, but even if we got past that, it would still be wrongheaded. To use the language of the Betamax decision, these tools have “substantial non-infringing use.” Disarming our limited supply of security researchers is nothing short of insanity.
  6. Allow government backdoor access to secure messaging applications like WhatsApp and Snapchat. British Prime Minister David Cameron and President Obama have called for mandatory backdoors so that intelligence agencies can scan for possible terrorist activity. The desire for this type of backdoor goes back to the Clipper chip, a notoriously flawed idea to escrow encryption keys with the government. Remember that attackers can still use “super-encryption” to defeat any backdoor scheme. That means that we all have to suffer Big Brother with very little benefit in terms of reducing terror.

How to really fix the software market
What strikes me about all these proposals is that they are not very likely to have a substantial effect on the software market. They are all reactive, attempting to target the bad guys rather than focusing on enhancing our own defenses. I think we are capable of producing radically more secure software than we do today. But we’re going to have to raise the bar for developers everywhere. The good news is that we don’t have to resort to making developers liable for vulnerabilities or other tricks.

We need to ensure that software buyers and sellers have the same information about what they are buying. We should start with minimally disruptive interventions such as requiring organizations to disclose information about how their software was designed, built, and tested and information about the people, process, and tools used. Imagine the “Security Facts” equivalent of “Nutrition Facts” label or “Material Safety Data Sheet” for software. Studies of labeling regimes have shown that even if consumers don’t use these labels at all, they still have a significant effect on the companies producing the products.

One thing’s for sure. Cybersecurity is on the government’s agenda for 2015.

A pioneer in application security, Jeff Williams is the founder and CTO of Contrast Security, a revolutionary application security product that enhances software with the power to defend itself, check itself for vulnerabilities, and join a security command and control ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Page 1 / 2   >   >>
BrianY331
100%
0%
BrianY331,
User Rank: Strategist
1/29/2015 | 5:23:21 AM
Re: Problematic solutions at best.
I think that the assumption that the government knows anything more about solving these problems than the technical community is fundamentally flawed.  They know a lot less and move a lot more slowly than we do.  They also really only have one weapon which is to threaten people with fines or jail and that's not something they ought to be doing to honest hard-working engineers.  They should be focused on doing that kind of thing to bad guys, not the good guys.  Sure, it's true that we good guys are easier to find than the bad guys, but so what?  If they can't handle the big jobs they should get out of the way.

The rate of successful prosecutions for bad guys is dismally small and even more dismal overseas where a lot of criminal activities are going on.  Rather than trying to "help" us they should be doing their jobs as police agencies.

--Brian
Securecore
50%
50%
Securecore,
User Rank: Apprentice
1/27/2015 | 1:52:41 PM
Middle ware
Starting with NON open source middleware and using a government agency secrecy model, many of the security issues to date are within the capabilities of unique middleware programs being developed. Unlike the typical "cybersecurity" firms, these methods MUST stay proprietary within the domain their designed for.. as the net of everything has exposed us all and open source means opening the door. Locking down execution prior to compilation, yes within a C++ base and providing unique multithreaded, asynchronous event processing with no garbage collection which exclude memory trapping to ensure proper program execution are all coming. Unique memory management and string processing with exotic threading will hamper and deter many malware efforts and expose the rest.
jleon570
50%
50%
jleon570,
User Rank: Apprentice
1/26/2015 | 12:46:59 PM
Problematic solutions at best.
It seems to me that "raising the bar for developers" isn't practical for the very reasons you cited as the reasons: the staggering complexity.

The number of "developers" in the world is too large to be hogtied.  Perhaps you could coerce developers over a certain size in terms of revenue or installations and by doing so you artificially make their software more expensive and give the smaller developers a government mandated advantage.  Only the natural market can set the bar for developers.  The government could, and perhaps should, set high standards for the software it purchases and perhaps by doing so, those high standards will trickle into the private sector.  But you can never get all the one-man contractors writing custom code for every business to comply with every best practice.

But then again, how can you put the burden on the developers when you have companies like Sony (just to name on of the millions) who store lists of internal passwords in unencrypted Excel spreadsheets in a "passwords" folder?  EVERY corporation in the world is littered with security idiots who think sending an unencrypted top secret file by SFTP is the same as a PGP encrypted top secret file sent by FTP.

I do have one major problem with one of your statements.  You said, "If you've been hacked, even if no privacy breach occurred, your customers have a right to know the details."  No, they don't.  As a customer, it would be NICE to know all the details if Target Stores found that a hacker had broken in and taken data from a planogram database, but I see absolutely no reason why I would have a "right" to know even the vague fact that it took place, much less any detail.  If in fact I DO have such a right, why would it be restricted to a cybercrime?  Shouldn't I also have the right to know the details of every crime committed against the business?  From an invasaion robbery to embezzlement to the slightest shoplifting?  I say no.
Joe Stanganelli
50%
50%
Joe Stanganelli,
User Rank: Ninja
1/25/2015 | 7:51:58 PM
CFAA
*sigh* Unfortunately, the CFAA needs revamping before it needs strengthening/broadening, because it in and of itself hurts cybersecurity efforts by penalizing independent security research.
LarchOye
100%
0%
LarchOye,
User Rank: Apprentice
1/23/2015 | 8:04:04 AM
"PROSECUTION"...
  1. Allow prosecutors to pursue anyone related to a hacking incident under Federal RICO statute. Given the difficulty of accurately identifying suspects, gathering evidence, and proving relationships in cyberspace, this approach seems ripe for abuse. There's nothing wrong with aggressively pursuing cyber criminals, but we can't forget about due process. How easy would it be to frame someone as a hacker if all that is required is a loose association? What if I friend the wrong person on Facebook or LinkedIn?

 

This really makes me feel obliged to bring up what is probably *THE* most important point dealing with the subject of cyber-prosection:

1) There is absolutely NO WAY to prove whether or not ANY piece of Digital or Electronic 'Evidence' used by the prosecution *ISN'T FABRICATED*.  This important factoid means that there is an ENORMOUS shadow of a doubt cast over every 'cyber-case'...  Since the For-Profit Prison Industry in this country CLEARLY constitutes a CONFLICT OF INTEREST with the American public; and certainly with the pursuit of "Justice".
planetlevel
100%
0%
planetlevel,
User Rank: Author
1/22/2015 | 5:34:25 PM
Re: Security Facts Labeling
Right on.  We need to look to models like building codes, FDA inspections, labels, material safety data sheets, etc...  to help fix the failures in the software market.  Right now, software buyers and users don't have nearly enough information about the software they are forced to use.  Yet they have to trust it with their personal information, money, health, etc...   Fixing this "market for lemons" means ensuring that everyone has the same information about the trustworthiness of software.  Only then can market forces encourage secure apps.
planetlevel
50%
50%
planetlevel,
User Rank: Author
1/22/2015 | 5:31:21 PM
Re: Not about codebase
The infographic is just a reminder that the size, complexity, interconnection, and criticality of our applications is continuously increasing.  All of those make security more difficult, but in combination they make a perfect storm for attackers.  We have to up our game, because the bad guys clearly are.
planetlevel
100%
0%
planetlevel,
User Rank: Author
1/22/2015 | 5:27:19 PM
Re: Security Facts Labeling
"Impressive" isn't exactly the word I would have chosen :-)  But I get your point.  That's why I spend all my waking time building tools to help stamp out these vulnerabilities.
Dr.T
100%
0%
Dr.T,
User Rank: Ninja
1/22/2015 | 4:23:50 PM
Re: Security Facts Labeling
It is really impressive that injection is still at the top of the list. That is not really default to solve. I guess old legacy system are not easy to change and becoming the target.
Dr.T
100%
0%
Dr.T,
User Rank: Ninja
1/22/2015 | 4:19:54 PM
Re: The internet needs a security makeover
Not only that but also a new mindset around security. We can not make internet secure, we need to start with that and try to find out a new approaches to address current security needs.
Page 1 / 2   >   >>
Election Websites, Back-End Systems Most at Risk of Cyberattack in Midterms
Kelly Jackson Higgins, Executive Editor at Dark Reading,  8/14/2018
Intel Reveals New Spectre-Like Vulnerability
Curtis Franklin Jr., Senior Editor at Dark Reading,  8/15/2018
Australian Teen Hacked Apple Network
Dark Reading Staff 8/17/2018
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2018-15504
PUBLISHED: 2018-08-18
An issue was discovered in Embedthis GoAhead before 4.0.1 and Appweb before 7.0.2. The server mishandles some HTTP request fields associated with time, which results in a NULL pointer dereference, as demonstrated by If-Modified-Since or If-Unmodified-Since with a month greater than 11.
CVE-2018-15505
PUBLISHED: 2018-08-18
An issue was discovered in Embedthis GoAhead before 4.0.1 and Appweb before 7.0.2. An HTTP POST request with a specially crafted "Host" header field may cause a NULL pointer dereference and thus cause a denial of service, as demonstrated by the lack of a trailing ']' character in an IPv6 a...
CVE-2018-15492
PUBLISHED: 2018-08-18
A vulnerability in the lservnt.exe component of Sentinel License Manager version 8.5.3.35 (fixed in 8.5.3.2403) causes UDP amplification.
CVE-2018-15494
PUBLISHED: 2018-08-18
In Dojo Toolkit before 1.14, there is unescaped string injection in dojox/Grid/DataGrid.
CVE-2018-15495
PUBLISHED: 2018-08-18
/filemanager/upload.php in Responsive FileManager before 9.13.3 allows Directory Traversal and SSRF because the url parameter is used directly in a curl_exec call, as demonstrated by a file:///etc/passwd value.