•

» incident response

PlayStation Network Hack – What You Don’t Know Can Hurt You

Posted on May 1, 2011 by Dan Berger in Main | 1 Comment

In a press conference late last week, Sony PlayStation Network executives confirmed that the recent hacking incident that exposed personally identifiable information and credit card numbers of all or part of the user database, was an exploit of a known vulnerability – just not one known to Sony.

The “external intrusion” has left 77 million PlayStation Network and Qrirocity users without access to the services or their personal data stored there for the past 10 days.  In the press conference, Sony Computer Entertainment CEO Kaz Hirai publicly addressed the security breach, the network shutdown and tentative restoration date, as well as Sony’s other plans to “make good”  to its  millions of loyal users.

Hirai-san stated that there’s “no evidence that credit card numbers, expiration dates or billing addresses” were stolen and that there have been no confirmed cases of credit card fraud relating to this incident. However, he later urged all PSN members to check monthly credit card billing statements for possible fraudulent charges. Previously, the company had stated that as many as 10 million credit cards may have been “exposed” but there was no “proof” that they had been stolen.

These seemingly incongruous statements may be the result of semantics, Japanese-English translation or both. Or perhaps it just shows how data security breaches by their very nature can create chaos or at least a lot of unknowns. The incubation period and extent of potential harm for stolen personal information can vary in length and degree. What is clear is that some hackers delight in infiltrating systems “just because they’re there,” most sophisticated and well-orchestrated attacks are driven by underground, malevolent economic pay-offs.

Sony’s reputation re-building efforts, proposed compensatory offers to members, network security enhancements and organizational changes are all admirable and necessary in the wake of this massive breach. But there’s also the hard truth that perhaps all of this could have been avoided. At Redspin,  we assess network infrastructure and applications against known vulnerabilities. We then take a “hacker’s eye view” and analyze and report on potential attack vectors. Our findings reports suggest improvements  to network infrastructure, tightening security controls, and hardening web applications.

We urge our clients to be proactive about security – implement a regular cycle of security testing, remediation, validation and retesting. Our Enterprise Solution provides a structured approach to institutionalize security as part of operations. And its certainly affordable – particularly when one considers the potential costs of a catastrophic breach.

 

The increasingly sophisticated threat landscape, is your information security program prepared?

Posted on September 26, 2010 by John Reno in Main | 1 Comment

The Washington Post reported this morning on the latest development related to Stuxnet malware. The Stuxnet code was designed from the bottom up to attack Supervisory Control and Data Acquisition (SCADA) systems, or those used to manage complex industrial networks, such as systems at power plants and chemical manufacturing facilities. The malware, which has been the subject of much discussion over the last month or so in the security and cyber war community, is capable of taking over systems that control industrial plants. This is the first report of attacks against nuclear facilities.

The malware uses four different zero-day exploits, two stolen certificates to get proper insertion into the operating system and a multi-stage propagation mechanism, starting with infected USB-sticks, ending with code insertion into Siemens S7 SPS industrial control systems. One of the Zero-Days is a USB-stick exploit that infects the computer the stick is put into, regardless of the Windows operating system version – Windows 2000 to the most modern and supposedly secure Windows 7.

I think what’s interesting about this is not so much the technical sophistication and highly targeted nature of the malware, but the policy issues that surface as a result. The government is in the midst of trying to sort out the roles various agencies will play in dealing issues ranging from cyber weapons to espionage. Earlier last week the Department of Defense’s newly formed cyber command advocated creation the creation of a separate, secure computer network to protect civilian government agencies and critical industries like the nation’s power grid against attacks mounted over the Internet. The Department of Homeland Security also is chartered with protecting the nation’s infrastructure, but most in the security community see little understanding of the threats and even less in the way of effective defensive programs.

Unfortunately, the picture in the commercial sector is not much better. The threat landscape for large enterprises includes well funded efforts at cyber crime, as well as state-backed efforts associated with cyber espionage aimed at stealing intellectual property. The challenges in dealing with this threat landscape are not just technical but cultural. Most of the CIO’s and CISO’s in the commercial sector have been hired because they are good at keeping things running (ensuring availability) and keeping down costs. In light of the current threat landscape, I would claim at least equal attention needs to be placed on building resilient networks that resist attack.

Service driven innovation in healthcare

Posted on August 31, 2010 by John Reno in Main | Leave a comment

This month’s edition of Harvard Business Review features an article on service driven innovation at Kaiser Permanente. Kaiser is well known in the healthcare industry as a leader in applying IT to improve quality of care and producing better business results. The organization routinely outspends its peers on IT as a percent of revenue and has always rejected the fee for service model that is often blamed for excessive healthcare costs across the industry.


What struck me as interesting about this article is that innovation initiatives are typically associated with expensive, top down endeavors aimed at producing new product categories. The approach at Kaiser is different in that the focus on service driven processes means that innovation can be done rapidly and economically. One example that is cited examines the process that nurses follow to exchange information between shifts. The status quo process took 45 minutes or more and delayed the arriving nurses first contact with their patients. This not only wasted time, but also often resulted in inaccurate information exchange, as well as unhappy patients. After analyzing the process and engaging the nursing teams, a simple breakthrough was identified that called for information exchange to take place with the patient’s at bedside rather than at the nurse’s station. This new process, coupled with supporting software to compile information in standard format throughout the nursing shift, led to much improved quality, staff satisfaction and increased quality of care.


To ensure that the service innovation process takes hold throughout the KP organization every project includes a “change package”. The package consists of a concise set of guidebooks describing the innovation, the process by which it was developed, the benefits for staff and patients and the metrics used to evaluate performance over time. Several versions of the package are targeted at line of business leaders, project managers and frontline staff.


I think this process of service driven innovation can be applied successfully in the information security domain. Incident response is one area that comes to mind. The process calls for coordination with many groups within the organization and the quality of results are driven as much by the thoroughness of the process preparation as the technical methods employed. Another area calling for process innovation is application security. The risk to the organization is acute, but often IT and information security teams get bogged down in reacting to the latest vulnerabilities rather than following a process to reduce risk and liability to the business.


We are in the midst of putting together a white paper that will examine many of these issues as they relate to healthcare IT security and service process innovation.

Healthcare Breach Fines – Legal defensibility and the implications for healthcare information security programs

Posted on June 21, 2010 by John Reno in Main | Leave a comment

Last week the media was buzzing with the actions of the California Department of Public Health (CDPH). The CDPH announced fines of $675,000 against six hospitals that had reported security breaches involving medical records. The legal basis for these fines and penalties are associated with two bills that amended California law in 2008, AB 211 and SB 541. Since the laws went into effect the CDPH has issued fines of $1.1M.

The major elements of the legal requirements associated with these laws include:

• Breach notification to the CDPH of unauthorized or unlawful access to and use or disclosure of medical information within 5 days after detection.
• A duty to prevent unlawful or unauthorized access to, and use or disclosure of medical information.
• An obligation to establish and implement appropriate administrative, technical and physical safeguards to protect the privacy of a patient’s medical information from any unauthorized access or unlawful access, use, or disclosure.
• Potential fines of $25,000 per patient ($17,500 per subsequent breach per patient) capped at $250,000 per event.

According to the American Health Information Management Association (AHIMA) 2,490 total incidents were reported in 2009 and 1,291 investigations were completed. Most of the reported incidents were unintentional breaches, but approximately 8% (191 incidents) involved malicious action by an insider or breach of an IT system.

Clearly this process is still in its early phases at the CPDH. But even at this early stage a number of things are clear. Healthcare organizations need to structure their processes to protect patient information. The information security team within the healthcare provider needs to assess the risks, develop a risk management program and deploy appropriate controls to protect the data as well as the systems and networks involved. Further, the security team needs to develop an incident response plan and work with their legal team to integrate legal defense considerations. Healthcare organizations that have proactively structured a security program where legal defense considerations have been well thought through will be in a much better position than those that are trying to conduct an investigation, analyze their options and construct legal arguments in the allotted five days.

Developing a proactive security program that works in close cooperation with the legal team as well as other organizations requires focused and consistent effort, but it is not new ground. The benefits also go far beyond simply being prepared for a CPDH investigation. Let’s look at a recommendation for a general process and framework for an information security program and it’s interaction with legal and other organizations. Shown below is a reference model with the primary organizations that the security team must interact with.

The objective of the security program is to minimize risk to information that is critical to the business while enabling business goals. The primary interactions in this area are with the line of business, finance and legal teams. The security team must codify the net results in terms of policy which will drive operational as well as quality and performance management decisions. Information security management is owned by the security team but interacts and primarily leverages operations, IT and HR. Information generated at this point contributes to the overall picture of situational awareness that guides both the business and the information security program. The security relevant aspects of quality and performance management for the business are owned by the security team but must work with the audit, development and QA teams. This function generates the reporting metrics (e.g. compliance to internal policies and regulatory requirements) that drives decisions for the business and the security team as well as contributes to the overall situational awareness picture. The overall output of this cycle is not simply to protect information but to allow better decisions to be made that drive the business forward.

So take it or leave it, but the guiding principle behind this view of a security program is one of leverage with other organizations, with business contribution as a driver. Let’s now look at some specifics behind working with the legal team, whether they are part of the internal organization or outside counsel.

Legal terms and language may be maddening to a technically oriented security team given the dependence on case law, room for interpretation and the interpretation of evidence. I don’t claim to be a lawyer, but I have checked with several in providing this guidance. The key here is not so much to lock on to a specific guideline, but to have some parameters for the conversation that you need to have with the legal team in advance of an incident. Let’s be clear, an incident will happen at some point. You will need a technically sound incident response plan. What I am suggesting is that you work with your legal team in advance and lock down a legally defensible plan as part of the information security program as well.

Now, since I have admitted that I am not an expert in legal defense let me guide you to one that I have developed a great deal of respect for on this subject. Please see the following article from David Navetta of the Information Law Group that was published recently in the ISSA Journal.

This topic of legal defensibility got started (in my mind) at the RSA conference this year. The leading contributor was Ben Tomhave. He pretty much gave momentum many of these ideas with his legal defensibility doctrine.

The problems of information security are hard. We need to cooperate with experts in many areas (legal and others) and not simply remain comfortable (even if we feel that technically we have covered the necessary bases).

State HIE deployments – Some thoughts from the field

Posted on June 16, 2010 by John Reno in Main | Leave a comment

Health and Human Services Secretary Kathleen Sebelius is one busy government employee. From announcements regarding Regional Extension Center Awards and Job Training Grants to the State Health Information Exchange Cooperative Agreement Program, it’s a daunting task to keep up with the acronyms and initiatives.

For the healthcare provider on the front lines, these announcements are just part of several waves of carrot and stick techniques that will ideally drive the U.S. healthcare system toward competitiveness. The carrots have already started coming in terms of grants and incentive payments. State grants (through governor appointed State Designated Entities (SDEs) and state Medicaid agencies) help states improve the exchange of healthcare information which will in turn have many benefits ranging from quality of care to cost reduction.

This sweeping effort reminds me of a huge product development effort on the level of a complex computer system or microprocessor. Given that I have been through more than my fair share of these development efforts, I dug out some notes that I have seen put to very effective use when teams at Intel, IBM and Microsoft and others faced complex endeavors. You might think of these like Stephen Covey’s Seven Habits of Highly Effective People, but for geeks.

1. Focus on tactics, not strategy – Andy Grove, Intel
2. Learn from others – Steve Jobs, Apple
3. Plan to throw one away – Frederick Brooks, IBM
4. Pilot as quickly as possible – Bill Gates, Microsoft
5. Implement in the lab rather that the conference room – Andy Bechtolsheim, Sun
6. Let the most important use cases lead, others will follow – Bill Harris, Intuit
7. Focus on information and users, gain critical mass as quickly as possible – Jeff Bezos, Amazon

But rather than go on and write a book about complex system development process, I thought I would stick to information security and offer a few insights to those that must secure these healthcare information exchanges.

Here are a few things to keep in mind with respect to information security and healthcare information exchange.

• Things will go wrong eventually – have an incident response plan; practice it.
• Make sure you have a CISO. I haven’t met very many in this sector (unfortunately).
• Invest in an information security assessment (yes, I realize it is self-serving).
• Derive policy from security goals and make sure it’s enforceable.
• Develop and maintain a risk management program (the only way to make stakeholders happy).
• Practice business continuity like elementary school fire drills.
• Take a similar approach to security awareness training.
• Review and act on your logs – enough said.
• Develop a threat model – your adversaries are bad, bad.
• Maintain adequate business associate oversight – trust no one.
• Harden your systems, run a patch management program under change control, etc. – this is basic stuff.

There is so much more, but hopefully I have given you a few things to think about.