Skip to content
Categories:

Getting things done – building and improving an application security program

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.

Posted in Main.

Tagged with , .

No comments

By John Reno – July 28, 2010

The final rule on meaningful use – an opportunity for healthcare process improvement and security program development

Earlier this week the CMS and ONC released the final Standards Rule for meaningful of electronic health records. This culminates a process in which the ONC received thousands of comments and struggled to reach a balance between specificity (presumed to make certification and implementation a simpler task) and generalization (which can enable more rapid innovation).


An analysis of the requirements can be daunting. For those who choose to go through the details of the requirements, key resources can be found at the Federal Register. Specifically, the Federal Register publication of the Meaningful Use regulation and the Federal Register publication of the Standards regulation. I have found the most useful summary in a recent article in the New England Journal of Medicine by David Blumenthal and Marilyn Tavenner. This reference includes a table with a summary overview of meaningful use objectives and their respective measures. This is a concise and useful description of the 15 core requirements for Eligible Professionals and the corresponding 14 core requirements for hospital organizations as well as the 10 discretionary requirements (of which 5 must be chosen). I have also put together a presentation regarding meaningful use that you may find helpful. Feel free to download it here.


From a security, privacy and compliance standpoint the implications of the final Standards Rule are quite significant. One of the core requirements sets a specific goal: implement systems to protect the security and privacy of patient data in the EHR. The corresponding measure calls for organizations to conduct a security risk analysis, implement security updates and correct identified security deficiencies.


A closer look at the security and privacy rules shows that the most prescriptive requirements involve transport layer security, message integrity and auditing/logging. Key highlights from the regulations are outlined below:


Encryption and decryption requirements for use of electronic health information


Usage guidelines – Any encryption algorithm identified by the National Institute of Standards and Technology (NIST) as an approved security function in Annex A of the Federal Information Processing Standards (FIPS) Publication 140-2.


Record actions related to electronic health information


The date, time, patient identification, and user identification must be recorded when electronic health information is created, modified, accessed, or deleted; and an indication of which action(s) occurred and by whom must also be recorded.


Verification that electronic health information has not been altered in transit


Standard – A hashing algorithm with a security strength equal to or greater than SHA-1 (Secure Hash Algorithm (SHA-1) as specified by the National Institute of Standards and Technology (NIST) in FIPS PUB 180-3 (October, 2008)) must be used to verify that electronic health information has not been altered.


Record treatment, payment, and health care operations disclosures


The date, time, patient identification, user identification, and a description of the disclosure must be recorded for treatment, payment, and health care operations, as these terms are defined at 45 CFR 164.501.


Now, let’s look at what this will mean in the healthcare community with a focus primarily on security, privacy and compliance programs. By now, I think most vendors and providers in the healthcare industry segment realize that the transition to widespread adoption and meaningful use of electronic health records is an opportunity for a major overhaul and upgrade of their workflow processes and the IT systems that support those processes. Many people in the healthcare community that I have talked with view this as similar to the challenges faced in the 80’s and 90’s when businesses transitioned to ERP systems. The transition can be a source of major disruption and pain, but ultimately a source of competitive advantage and business agility.


The transition should also be viewed as an opportunity for major enhancements to security, privacy and compliance programs. Information security stakeholders at healthcare organizations need to look at the transition to meaningful use of electronic health records not simply as a set of requirements that call for risk analysis, encryption and auditing/logging, but an opportunity to modernize their information security programs, revitalize governance mechanisms and institute risk management as a core, ongoing process. Pragmatically, healthcare organizations must also realize that for the next 12 to 18 months EMR vendors will be focusing on certification as their number one priority. Certification is a necessity for meeting the requirements of the meaningful use rule and a business driver for the EMR vendor community. Realistically, this means that security will not be the priority that it should be. As a result, more of the burden of systems and application security will fall on the shoulders of deploying organizations.


In summary, the transition to meaningful use of electronic health records is a very ambitious program. The most successful organizations will look to set their own goals and invigorate their security, privacy and compliance programs.

Posted in Main.

Tagged with , , .

No comments

By John Reno – July 17, 2010

Hard work – The ONC privacy and security tiger team

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 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.

Posted in Main.

Tagged with , , .

No comments

By John Reno – July 8, 2010

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

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.

Posted in Main.

Tagged with , , .

No comments

By John Reno – June 27, 2010

Healthcare Web Applications – The Security Achilles Heel

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.

Posted in Main.

Tagged with , , , .

1 comment

By mmarshall – June 24, 2010

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

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).

Posted in Main.

Tagged with , , .

No comments

By John Reno – June 21, 2010

State HIE deployments – Some thoughts from the field

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.

Posted in Main.

Tagged with , , , .

No comments

By John Reno – June 16, 2010

A bad Apple…

This week iPad owners had their emails leaked via a security vulnerability in the way iPads registered with AT&T’s 3g service. Approximately 114,000 email addresses were brute forced from a script that was supposed to recognize an iPad owners ICC ID ( an “unique” identifier” which turned out to be predictable) and supply them an AJAX response of that ICC ID’s associated email address.

The grey-hat security group that found the vulnerability brute-forced ICC ID’s and analyzed the resulting successful request/responses using a PHP script and faking the iPad user agent. This exploit was apparently released in the hacker scene before AT&T removed the functionality.

What’s the big deal?

Although email addresses are usually harmless a large number of high ranking military and government officials registered their .mil and .gov addresses with their iPads, not to mention celebrity email addresses that are usually hush-hush pieces of information. Knowing these addresses opens them up to a large number of spammers and would-be social engineers that will now be checking every login field on the internet for accounts belonging to them (and we all know celebs use strong passwords, yes?).

Many will have to be changed/removed entirely, some mail systems will need to be re-examined for hardness, spam rules will need to be tweaked, etc.  A lot of IT elbow grease will go into preventing damage from Apple’s and AT&T’s debacle. Early adopters of technology should always consider they are basically in the beta-test phase as far as security is concerned.

Remember, an iPad a day doesn’t keep the hackers away!

**UPDATE**

Praetorian Security released a blog that has the actual script used here.

Posted in Redspin Labs.

1 comment

By jhaddix – June 9, 2010

Focus first on security goals, compliance will follow

I was depressed earlier this week from conversations with a security vendor and a system developer. They both had developed, more or less, the same point of view. The security vendor said, “Compliance is what sells”. The system developer said, “Failed audits are what can get the attention of management.” Compliance is certainly necessary for most companies, whether driven from the standpoint of adherence with internal policies or government regulations. In many cases compliance requirements have provided the impetus and funding for a first class information security program. The problem is that compliance does not necessarily lead to security. Ask any shareholder from TJX.

So then what path can be taken assure security for a given business? Unfortunately, there are no silver bullets available at any price (ask Google). However, structuring a continuous security management process around several important elements can yield results that strengthen the business both qualitatively and quantitatively. These key elements include understanding the threat environment, designing security in as a systems requirement, managing risks and winning the economic contest with adversaries.

For this discussion we’ll focus on security goals and designing security in as a system requirement. In this case the systems we need to consider are not just applications but the networks, policy enforcement points, virtual machines, and servers that support them. Security goals consist of the following:

• Authentication
• Authorization
• Confidentiality
• Data/message integrity
• Availability
• Non-repudiation
• Accountability

These need to be defined in terms of specific, measurable and documented requirements. As such they become features of the overall system, but also contribute to a larger set of processes by which the system is developed, tested, deployed and maintained. Without shared understanding of security goals and requirements among stakeholders such as developers, architects, testers and operations staff, the business is put at risk and efforts to add security after the fact will be frustrating if not impossible. As an example of what not to do, consider the Microsoft SMB protocol. Security goals were never established in initial versions. Later versions still suffered from deficiencies ranging from lack of documentation to no requirement for client authentication to highly complex cross-domain deployment. Today at least 12 dialects of SMB exist that continue to offer attackers a rich target. Over time, Microsoft has emerged as a major proponent of security goals and designing in security, but there are innumerable legacy systems out there where the damage has been done.

What then is the optimum path to a secure and compliant business? My recommendation is to start with security goals, build processes from aggregated goals associated with the business critical systems, adapt internal policies to support the security goals and then extend internal policies to comply with regulatory requirements. Working the process in reverse, starting with compliance to regulatory requirements, means clear security goals may never surface. Without the foundation of security goals for the systems that support the business, security policies and processes are difficult to manage, internal and regulatory compliance is costly to maintain and the business is put at risk.

Posted in Main.

Tagged with , , .

No comments

By John Reno – June 6, 2010

Attack Surface Reduction – An often overlooked element of application security

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.

Posted in Main.

Tagged with , , , , .

No comments

By John Reno – May 30, 2010