•

» application security

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.

 

Healthcare Web Applications – The Security Achilles Heel (Part 2)

Posted on January 27, 2011 by Dan Berger in Main | Leave a comment

Last June, one of my colleagues at Redspin blogged about his concern that security flaws in software applications that house ePHI (electronic protected health information) represent a big threat. We had just completed a security assessment for a client and had found it relatively easy to access their customer portal using a common SQL injection technique. ePHI  records represent tempting targets for cyber crime as they typically include a wealth of personal info (name and address, SSN’s, credit card numbers, DOB and more).

The healthcare industry is currently very motivated to deploy EHR systems, increase interconnectivity via HIE’s, and launch new web applications. As data is made more accessible to more audiences, the risk of a breach increases too. The scope of a HIPAA Risk Analysis should include software applications but be sure to hire a company with specific application penetration testing expertise. Make sure your provider is competent, has relevant experience and applies best practices, starting with the Top 10 Web Application Vulnerabilities list as outlined by the Open Web Application Security Project (OWASP).

Another area of focus should be your internal patch management process. Effective maintenance of your current day-to-day IT operating systems and applications is essential but be sure to conduct an inventory of older applications as well. They may have been developed by people who are no longer with your organization.  Some may perform tasks that are very mundane, highly specialized and/or are rarely used. At Redspin we often uncover these “out-of-sight, out-of-mind” applications in our HIPAA Risk Analysis process. Fortunately we have an application penetration testing methodology that is applicable to both web applications and non-web applications

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.

Getting Things Done – Building and Improving an Application Security Program

Posted on July 28, 2010 by John Reno in Main | 1 Comment

It seems that the realization that applications provide the most dangerous attack vector and the most common area of exposure for enterprise data has begun to take hold with the healthcare and financial services organizations that I have been talking to recently. The natural question that results is what should be done. What is the best approach to building or improving an application security program?

Often security teams look to industry analysts for their views on trends and developments with respect to security, compliance, privacy and cyber crime in hope of educating executive staff and gaining funds. Such an approach can be useful. In fact, the Ponemon Institute released last week a study of the cost of cyber crime over the last nine months in 45 U.S. companies. The median annualized cost of cyber crime in these organizations was $3.8M and companies reported more than one successful attack per week. While such facts can help make the case for investment in security, I would recommend a more thoughtful, structured approach that has immediate impact but builds for the long term.

In terms of building a new application security program or improving an existing one, I am partial to focusing on two key areas: creating leverage with the organization and replicating what has been successful in other enterprises. Ultimately both these activities help gain executive support and form the foundation for a well structured and effective program.
Let’s look at the first area which seeks to maximize leverage with other organizations within the enterprise. In previous posts I have referenced the diagram below to illustrate the point of how information security interacts with other groups within an organization.


An effective application security program requires alignment with the lines of business as well as sponsorship and coordination between development, QA and operations. Ultimately, all the organizations need to be brought on board with the process and support of the application security program whose goals should include:

• Risk management driven decisions

• Clear direction on how to achieve application security

• Cost reduction through standard, repeatable process

• Increased code quality

The second area of focus is to evaluate what has been successful in other enterprises. An excellent resource for this is the Building Security in Maturity Model or BSIMM. This initiative is a descriptive look at application security programs across thirty companies in sectors such as financial services, healthcare, technology and independent software vendors. Participating companies include organizations such as Bank of America, Capital One, EMC, Intel, Google, Microsoft, Nokia, Thomson Reuters and VMWare.

BSIMM lays out a software security framework consisting of twelve practices organized into four domains. The domains consist of the following:

• Governance – the practices that enable management, organization and measurement of an application security program.

• Intelligence – the collection of knowledge used in carrying out the program.

• Secure software development lifecycle touchpoints – activities supporting the analysis and assurance of applications.

• Deployment – practices that interface with operations, security and support organizations.

The domains, practices and associated business goals are shown in the table below.


The BSIMM initiative further lays out a maturity model for each of these areas identifying three levels of maturity with various practices that reflect program development. Perhaps most interesting is to look at the practices that the companies participating in the program have in common. These may not be a direct fit for every program, but you can conclude that they are found in many highly successful application security programs.  The objectives and activities associated with the common practices are outlined below.

Hopefully these ideas will help to refine and develop your application security programs. I would encourage a close look at the BSIMM document.

Hard work – The ONC privacy and security tiger team

Posted on July 8, 2010 by John Reno in Main | Leave a comment

Last week I attended the Healthcare IT Standards Committee meeting. The all day meeting covered a wide variety of topics ranging from the interoperability framework, NHIN governance as well as updates from several teams, including the security and privacy tiger team. The Office of the National Coordinator (ONC) who heads this effort has done a great deal of hard work in gaining the perspectives from a broad set of constituents and communicating progress. Many commercial products and services have working examples in healthcare information exchange on a broad level.

My focus for this discussion has to do with privacy and security. Much of the discussion last week involved transport layer security. Clearly the problem is broader than that. In working on past projects with this sort of scope, I have found that a common understand can be found through the adoption and use of a threat model. There are several strong approaches that can be considered for use. I have found the following to work well.

The general idea is to apply a threat model to a set of applications communicating over NHIN. The process recommends a step by step approach of identifying security objectives; reviewing the application in terms of components, data flows and trust boundaries; decomposing the application in terms of components to identify areas where security needs to be evaluated; creating a structured list of threats; and enumerating likely vulnerabilities associated with the class of application in development. Microsoft advocates a threat classification scheme known as STRIDE. This scheme aims to characterize the threats with respect to the exploit that may be employed. This acronym stands for:

• Spoofing Identity
• Tampering with data
• Repudiation
• Information disclosure
• Denial of service
• Elevation of privilege

These areas provide a helpful mechanism for enumerating threats to the application. Closely associated with this process is a scoring scheme to help evaluate risk to the application. Another acronym applies to this problem as well: DREAD.
DREAD attempts to quantify, compare and prioritize the amount of risk presented by a given threat. It stands for:

• Damage potential
• Reproducibility
• Exploitability
• Affected users
• Discoverability

Typically each of these areas is assessed on a scale of 1 to 10 with 10 referring to the most severe risk. As always risk needs to be evaluated in terms of both probability and impact.

Perhaps the application of these ideas will be helpful as NHIN takes shape.

Electronic prescriptions of controlled substances – a key area where information security is paramount

Posted on June 27, 2010 by John Reno in Main | 1 Comment

Earlier this month the Drug Enforcement Administration (DEA) revised their regulations surrounding the writing of prescriptions for controlled substances electronically. The rule had been published in March on the Federal Register and is now effective. Streamlining the process associated with the e-prescribing of controlled substances has many benefits including cost reduction and improvement in the quality of care. At a recent conference some of the challenges in this area were discussed by Leisa Jenkins, executive director of CareSpark. In the region that the CareSpark RHIO serves, fraud associated with the use of controlled substances is rampant. Patients routinely take advantage of the lack of consistent medical record and cross-state jurisdictional issues to gain fraudulent access to controlled substances. Solving this problem requires that provider organizations invest in information systems and processes that address the issue. Security, privacy and compliance requirements are significant.

This area is a clear example where information security is a business enabler, a topic that I have discussed in earlier posts. It is also an area where the provider organization must ensure that they have thought through the legal defensibility associated with their information security programs.

Let’s now look at some of the security guidelines and requirements necessary for a provider organization to take advantage of e-prescribing. These recommendations apply generally to e-prescribing overall, but look closely at the problem in the context of controlled substances.
One of the critical security issues in this area is authentication. In order to meet the requirements mandated by the DEA an e-prescribing application must comply with security needs on several levels. At the heart of these requirements is two factor authentication. This is necessary for creating a controlled substance prescription, signing the prescription and obtaining the necessary credential. As usual, the National Institute of Standards and Technology (NIST) have provided guidance in this area. Specifically, the guidelines put forward in NIST special publication 800-63-1 provide recommendations. The important take-away is that authentication in the area of e-prescribing for controlled substances requires two factor authentication at NIST assurance level 3. There are several ways to meet this requirement but some technical approaches are rather advanced. Product/service combinations that I would recommend are the solutions from Anakam. In evaluating an authentication solution for this area it is not only a matter of strong security, but also dealing efficiently with the ease of use and workflow considerations in a medical environment.

Beyond authentication there are many additional challenges to deploying and sustaining a secure environment for a mission critical application such as e-prescribing. A useful point of reference is provided by Center for International and Strategic Studies (CSIS). In this report they describe the 20 critical controls necessary for effective cyber defense. Much of the work has been drawn from the experience of blue team members inside the Department of Defense. A conclusion of this report is consistent with our own experience at Redspin that application security is an area where significant investment is required. Information security teams that are charged with supporting mission critical applications such as e-prescribing need to focus not only on perimeter controls, but also on additional areas such as log monitoring, vulnerability remediation process and malware defense.

In subsequent posts I will delve further into some of the application security specifics, as well as discuss the aspects of legal defensibility associated with an information security program in this area.

Healthcare Web Applications – The Security Achilles Heel

Posted on June 24, 2010 by mmarshall in Main | 1 Comment

At Redspin we have a unique view of the security space, given that we are hired to perform security assessments of customer web applications all the time. Our clients want to know if a hacker can access their Electronically Protected Health Records. The answer, sadly, is often yes. Many times it is dreadfully easy. This week we accessed a customer portal chock full of EPHI using the classic ‘or 1=1;– trick (SQL injection). For those not technically inclined, this string is usually entered into the username field. It tricks the application so that instead of checking whether the username and password are valid, it checks to see if the username and password are valid or if 1=1. Since 1=1 is always true, a poorly coded application will log the nefarious hacker in (often as the global administrator or system user).

It’s unfortunate that the healthcare space is subject to these flaws, as most of these applications house thousands of EPHI records. These systems commonly have SSN’s, Credit Card Numbers, addresses, DOB’s, essentially everything a nefarious bad guy would need to steal many identities. In addition many people consider their medical information to be their most private data.

Another example is an advisory we just published on Cross-Site Scripting Vulnerabilities and database access in OpenEMR an open source healthcare records application.

It’s not just the small players either, Anthem Blue Cross recently disclosed that over 200,000 records were potentially breached on their website. Many security problems we see are obvious and with basic effort, an organization can be much more secure. According to the report attorneys looking for information for a class action lawsuit against Anthem were able to gain access to the EPHI. This implies that the breach and the flaw were not complicated and didn’t require world class hacking skills. Given that the California Department of Public Health is starting to dole out fines (Healthcare Breach Fines), it will be interesting to see if they hit Anthem with the maximum fine.

The bottom line: if you have EPHI accessible via your Internet facing web applications, perform your due diligence. At Redspin we always recommend starting with the best practices that the Open Web Application Security Project (OWASP) has outlined in their Top 10 Web Application Vulnerabilities list.

Attack Surface Reduction – An often overlooked element of web application security

Posted on May 30, 2010 by John Reno in Main | Leave a comment

In industry surveys ranging from the Symantec Threat Report to Gartner analyst reports, application security is constantly cited as the most significant area of risk for enterprises and the most prevalent threat vector for cyber crime. It certainly makes sense, why bother to spend time on reconnaissance when the front door is wide open?

Many organizations have begun to spend a great deal of energy and money to secure applications. Popular approaches include code review, threat modeling, source code analysis and black box testing. Often overlooked is the rather fundamental practice of reducing the attack surface of the application.

During development and configuration of a system and the associated application the software must typically expose both customer and business assets through network ports, database access, APIs, web services and the user interface. The entire collection of entry points in a product is called its Attack Surface. These form the ways in which an adversary can attack a system. A big attack surface generally means big security issues, or often more time and budget dollars dedicated to protecting the system. It’s also important to remember that channels to local resources are not the only vectors for attack, remote resources must also be kept in mind.

Generally, when a software system is architected, implemented and configured, the top of mind issue is about providing useful functionality that meets business goals. From a security point of view, however, the design and deployment teams must also think about turning things off as well as on. From a design standpoint this involves reducing the amount of code that is executing by default, running with user privileges rather system, reducing functionality and data accessible to unauthenticated users and limiting the damage if access points are exploited. From a system configuration point of view this involves turning off unnecessary services, providing access only to required authorized users on specific subnets, and using strong ACLs to control access to resources.

The security community has done a relatively good job with respect to understanding which attack vectors are more likely targeted by adversaries.  Given that perspective, keep the following in mind:

• Minimize the use of scripting engines and controls such as ActiveX, JavaScript or VBScript.
• Avoid symbolic links as these are likely targets.
• Restrict file permissions to the fullest extent possible.
• Minimize the number of services that must run as root.
• Keep up with vulnerability research and build an effective patch process.

A useful practice is to put together a design guideline for developers suitable to your design environment and the business and security requirements associated with your system. Further, at deployment time, a security configuration guide and checklist of security best practices is recommended. Interestingly, some in the industry such as SAP have invested even more heavily in this area. SAP Labs has developed and begun pilot deployment of an Eclipse extension that uses a more formal process to measure attack surfaces. Their method involves summing the damage and potential-effort ratios (DER) of relevant resources. The relevant resources of an application include its channels, such as TCP ports; methods, such as API calls; and data, whether persistent, in memory, or in transit. The DER of a resource is the ratio of potential damage to the effort required to breach the resource. The SAP tool discovers application resources and combines that data with DER numbers to generate attack surface metrics for software components. While the discovery of resources is fully automated, the tool requires context specific configuration based on experience, judgment, and a threat modeling process.

Given the complex nature of deploying SAP software securely it’s not surprising that they have invested in this area. However, all systems can benefit immediately from simply measuring the potential avenues of attack and understanding the impact. This practice can be particularly beneficial for complex systems with many configuration decisions. In the healthcare sector, where Redspin has done many information security assessment projects, a good example is healthcare information exchange systems. A further example with broad deployment across many sectors is CRM systems.

Whether through design reviews, deployment guides or development tools, the practice of reducing the attack surface associated with an application has the potential to quickly yield a high return on investment.

Cloud Security – New Worries or the Same Old Stuff?

Posted on May 12, 2010 by John Reno in Main | Leave a comment

Cloud service based deployments have become commonplace in industry segments ranging from financial services to healthcare. I have discussed in earlier posts how the cloud services model will come to dominate important areas such as healthcare information exchanges. The economic model is highly attractive across a broad range of business problems. Several years ago as the business models and technical foundations for cloud computing were taking shape I helped form the cloud security alliance. One area of frequent debate was whether the cloud services paradigm called for new approaches to security. Then as now, I think the debate is still valid. My personal opinion is that the security and risk fundamentals remain the same, but the pressure points are different.

Perhaps an example would be useful to consider. Application security is a critical consideration whether you ship a CD (you know some really cool software still ships on a CD these days) or ship bits to Amazon AWS. Often the top of mind issue for developers tasked with the problem of application security is confidentiality – basically protecting sensitive data from cybercriminals and malicious business partners or insiders. Sometimes overlooked are application security issues (that are amplified in cloud services deployments) related to integrity. Consider an attack in which a virtual machine instance is injected into a cloud system such as Google App Engine or Microsoft Azure. Such cloud malware could serve many purposes for the attacker ranging from eavesdropping to data modification. Given that the attacker has done sufficient reconnaissance and is able to convince the cloud system to treat the new instance as a valid VM associated with the particular service, the cloud system redirects user requests to the malicious service implementation and the adversary’s code is executed.

The countermeasure to this threat falls back on the usual security principles. Perform an integrity check prior to using a VM instance for incoming requests. This can be done by storing a hash value of the original VM image and comparing this value with all new service instance images. The attacker can presumably still crack the hash value comparison, but the risk is dramatically reduced.

Perhaps in a later post I will discuss cloud service flooding attacks. An unpleasant thought for those who are paying the bill.

HIE’s – Now That the Funding is Complete, What Will the Operational Environment Look Like?

Posted on March 22, 2010 by John Reno in Main | 1 Comment

Last week the Department of Health and Human Services (HHS) announced an additional round of $162M in funding for Healthcare Information Exchanges. Combined with the state grants announced in February, this brings total funding to $547M. This means that all the states and state designated entities are on a path towards implementing the vision of the Office of the National Coordinator for Health Information Technology (ONC) laid out in their strategic plan.

The next step in the process calls for states to develop and align strategic and operational plans that cover what the ONC has termed as the five essential domains: governance, finance, technical infrastructure, business and technical operations and legal/policy. These plans are critical because strategic and operational plans must be approved by HHS before the states are free to begin to use HIE funds for implementation purposes. The plans are also critical to ensure coordination around standards and expand the use of HIE to a national level.

As one might expect this has created a great deal of activity in the healthcare IT sector as vendors position themselves for the operational phase associated with the state funding. As we enter this next phase in the evolution of HIE’s one of the major challenges to be overcome in driving HIE success is associated with ensuring security and privacy, as well as efficiently demonstrating compliance with HIPAA and HITECH requirements. With user requirements ranging from large hospitals to small physicians’ offices, answers to basic questions such as appropriate technical protection mechanisms and access controls present significant challenges. To a certain extent, forming the appropriate answers to questions of security and privacy requires definition of the compute and storage model that will be most prevalent in the environment.

In many respects, the leading model that is emerging in the HIE market is that of a cloud services based platform. In this model the cloud service provider is responsible for providing highly scalable services, authorization, access control, audit logging and data protection. Many vendors such as Axolotl, Covisint, IBM, Microsoft HealthVault/Amalga and Medicity have announced offerings in some form. These have included API’s that allow specialized applications to be developed rapidly while taking advantage of the core infrastructure services. Example applications range from clinical decision support to meaningful use reporting. An illustration of this framework is shown below.


The platform as a service model can be very powerful in the HIE environment because security and privacy services can be leveraged by the applications as well as the providers and consumers of the information. However, for rapid deployment and efficient ongoing operations it is critical that the providers of healthcare cloud services communicate security, privacy and compliance practices and procedures to customers in a transparent fashion. The hospitals, laboratories and physician practices that form the customer base of the HIE need to be able to understand this information and ensure that their security, privacy and compliance needs are met.

A further critical requirement in this model is for the API’s to support a secure ecosystem with common security controls that have been thoroughly tested. I think the emerging nature of the HIE market presents an excellent opportunity for platform vendors to coalesce around a common set of application security controls such as OWASP Enterprise Security API. Adoption of ESAPI would provide consistent application protection as well as leverage for both cloud platform providers and application developers.

As the HIE market evolves through this important phase of development it will be critical to continue to look for additional areas of leverage in the areas of privacy, security and compliance among the many stakeholders.

1 2   Next »