The BizSec Podcast is THE podcast that brings information security concepts and news into the boardroom, translating geek into business. Each episode we’re going to be talking about information security and technology security issues that matter to business, not just the technologists. We’re glad to have you subscribed on iTunes, Youtube or however you’re finding us and we always appreciate your 5-star reviews. Follow the conversation with us on Twitter @bizsecpodcast and find more information, links and show notes at BizSecPodcast.com.
- Dave talks about testifying in front of Congress about security issues in the Healthcare.gov system – what’s the upshot?
- Chicago Mercantile Exchange disclosed that they were breached in July – what we know and what we don’t yet.
- NIST releases a new draft Cybersecurity Framework – is it any good?
Dave Kennedy Testifies to Congress
This past week Dave testified in front of the U.S. House of Representatives Committee on Science, Space and Technology. He was discussing security issues with the Healthcare.gov systems, including the website and supporting infrastructure. Dave’s company (TrustedSec) did some non-invasive testing and even without going too deeply was able to identify some critical security issues. One of these tests, for instance, uses the Auto Complete feature in the website’s search function to look for past searches that indicate someone had tried to attack the site. While he was in the hearing he received an email from someone watching who had also done some testing and found several other critical security issues.
To put the size and complexity of the Healthcare.gov system in perspective, NASA had between 10,000-200,000 lines of code (a standard measure of application size and complexity). The Healthcare.gov site reportedly has 500 Million lines of code – that’s 2,500 times larger! One of the reasons for this is the natural expansion of the size of applications and systems. Another is the difference between the programs – in the 1960s the President set a goal and the bureaucracy was left out of it. In 2013 the government’s computer/technology procurement, development and implementation processes have grown large and complicated. That makes deployment of important information systems difficult, expands the timeframe and makes security harder.
Chicago Mercantile Exchange intrusion in July
News was released this week that the Chicago Mercantile Exchange had an intrusion in July. This isn’t the first time an Exchange or Market has been targeted. NASDAQ and the New York Stock Exchange have both been hit by attacks in the past couple of years, and a report released in July showed that 67% of American exchanges have fought off intrusions. This report also mentioned the critical need for exchanges to recognize the systemic risk of cybercrime. In fact, the Depository Trade and Clearing Corporation has said that cyberattacks are the number one threat to financial markets.
Details of the CME intrusion have been sparing. The Group claims the attack successfully compromised some credentials from the ClearPort trade clearing system. In response CME Group forced a credential change to customers who were potentially impacted. We don’t yet know how the intrusion happened, how it was discovered or how CME knows they have successfully contained and recovered from the event.
Reuters reports on the Chicago Mercantile Exchange intrusion
Bloomberg reports on the Chicago Mercantile Exchange intrusion
Publication of a report on systematic risk to global securities markets from cyberattack
Cybersecurity Framework for Critical Infrastructure
This week the National Institute of Standards and Technology (NIST) released a preliminary cybersecurity framework document for public comment. The framework is interesting in that it is maturity-based, meaning it is easier to communicate where an organization is, as well as where it is going. The framework is also interesting in that it puts a lot of weight on detecting, remediating and recovering rather than simply preventing. In this way it is closer to business continuation planning and a more agile approach to cybersecurity.
This site claims Apollo 11 had 145,000 lines of code. It’s not clear if they accounted for the comments (segments of non-code in the files that explain what the code does) which are not typically considered to be part of the lines of code count.
From an interview with the lunar landing engineers. One of them states that there were fewer than 10,000 lines of code. He may have been talking about just the lunar lander, however.
An infographic comparing many different systems and their lines of code count.
A study analyzed hundreds of millions of lines of code to find a standard defect rate. They came up with a figure of .66-.98 per thousand lines of code. Note that this is for finished, polished code with many years in the development cycle to remove these errors. The healthcare.gov site was launched before it went through any kind of security testing, and the Quality Assurance process was likely also cut or shortened. I’d estimate the defect rate on the higher side, but even if you use the rate of errors that NASA achieved in the shuttle (.11/KLOC) the healthcare.gov site would have 55,000 defects. If only 1% of these are security flaws you’re still looking at over 500 potential security flaws. That’s a very conservative number but it still very large.