Web Security – Are Regulations Falling Behind?
Sony, Facebook, Twitter, WordPress, Iranian State sites..as the hacking continues through Web applications, one has to wonder who’s on first? With over 250M websites out there, most of which are insecure, hackers have a huge playground to work with. Inertia, budget, and lack of knowledge are the common reasons behind lack of efforts in securing websites. If the risk of getting hacked isn’t enough of a motivating factor, what would drive companies to protect their Web infrastructure? What about regulations?
Let’s look at the some of the existing regulations and see why these haven’t been a driving force for organizations to improve security for their websites.
Gramm-Leach-Bliley Act (GLBA)
The Gramm-Leach-Bliley Act (GLBA), also known as The Financial Modernization Act of 1999, was enacted to ensure protection over customer’s records and information. Rules and provisions make up the requirements for financial institutions to (a) ensure protection of the security and confidentiality of customer’s nonpublic personal information, (b) implement administrative, technical, and physical safeguards, (c) protect against anticipated threats and hazards to information security, and (d) protect against unauthorized access to or use of information. Sounds good, right?
If we just focus on the sections on Access Control (as clarified by FFIEC), there various subsections that provide guidance on Authentication, Network Access, Operating System Access, Application Access, and Remote Access. If we zoom in further into Application Access, here’s roughly what we get: “Financial institutions should control access to applications by using authentication and authorization controls appropriately robust for the risk of the application, monitoring access rights to ensure they are the minimum required for the user’s current business needs, using time-of-day limitations on access as appropriate, logging access and security events, and using software that enables rapid analysis of user activities. All valid points but no mention about secure code, vulnerabilities etc.
Health Insurance Portability and Accountability Act (HIPAA)
In 1996, the Health Insurance Portability and Accountability Act or the HIPAA was endorsed by the U.S. Congress. The HIPAA Privacy Rule, also called the Standards for Privacy of Individually Identifiable Health Information, provided the first nationally-recognizable regulations for the use/disclosure of an individual’s health information. Without going into all the other details, if we just look at the technical safeguards of the HIPAA law, here’s what’s covered: Access Control. A covered entity must implement technical policies and procedures that allow only authorized persons to access electronic protected health information; Audit Controls. A covered entity must implement hardware, software, and/or procedural mechanisms to record and examine access and other activity in information systems that contain or use e-PHI; Integrity Controls. A covered entity must implement policies and procedures to ensure that e-PHI is not improperly altered or destroyed. Electronic measures must be put in place to confirm that e-PHI has not been improperly altered or destroyed. Transmission Security. A covered entity must implement technical security measures that guard against unauthorized access to e-PHI that is being transmitted over an electronic network. Again, a lot of details about access controls which are good and required but no details on Web applications and securing the code.
The North American Electric Reliability Corporation Critical Infrastructure Protection (NERC CIP)
The North American Electric Reliability Corporation (NERC) is a nonprofit corporation designed to “ensure that the bulk electric system in North America is reliable, adequate and secure.” NERC maintains comprehensive reliability standards that define requirements for planning and operating the collective bulk power system. Among these are the Critical Infrastructure Protection (CIP) Cyber Security Standards, which are intended to ensure the protection of the critical cyber assets that control or effect the reliability of North America’s bulk electric systems. In 2006, the Federal Energy Regulatory Commission (FERC) approved the security and reliability standards proposed by NERC, making the CIP Cyber Security Standards mandatory and enforceable across all users, owners and operators of the bulk-power system. Here’s the description of a requirement 4 in CIP: Cyber Vulnerability Assessment — The Responsible Entity shall perform a cyber vulnerability assessment of the electronic access points to the Electronic Security Perimeter(s) at least annually. The vulnerability assessment shall include, at a minimum, the following: R4.1. A document identifying the vulnerability assessment process; R4.2. A review to verify that only ports and services required for operations at these access points are enabled; R4.3. The discovery of all access points to the electronic security perimeter; R4.4. A review of controls for default accounts, passwords, and network management community strings; R4.5. Documentation of the results of the assessment, the action plan to remediate or mitigate vulnerabilities identified in the assessment, and the execution status of that action plan. Again, no specificity on Web applications, finding vulnerabilities, remediation plan etc.
The Federal Information Security Management Act (FISMA)
The Federal Information Security Management Act (FISMA) requires that all federal agencies document and implement controls for information technology systems that support their operations and assets. Standards and guidelines have been developed and published by the National Institute of Standards and Technology (NIST). FISMA and NIST guidelines do a fairly reasonable job of defining various controls under system and communications protection controls. Some of the controls in this section include cryptography, mobile code, virtualization, session authenticity, information at rest etc. The standard and the NIST guidance also talks about security controls to assess and monitor all systems on a regular basis. Although much better than others, it falls short of calling out comprehensive Web applications security processes.
The Payment Card Industry (PCI) Data Security Standard (DSS)
The Payment Card Industry (PCI) Data Security Standard (DSS) was developed to encourage and enhance cardholder data security and facilitate the broad adoption of consistent data security measures globally. The PCI DSS is a multifaceted security standard that includes requirements for security management, policies, procedures, network architecture, software design and other critical protective measures. This comprehensive standard is intended to help organizations proactively protect customer account data. PCI has come closest to defining and emphasizing Web applications security in its standard.
Requirement 6.6 clearly defines the requirement for securing Web applications: For public-facing web applications, address new threats and vulnerabilities on an ongoing basis and ensure these applications are protected against known attacks by either of the following methods:
• Reviewing public-facing web applications via manual or automated application vulnerability security assessment tools or methods, at least annually and after any changes
• Installing a web-application firewall in front of public-facing web applications.
A couple of issues that continue to plague PCI DSS as it relates to Web application security are: # 1 option of having a web-application firewall (WAF) or assessment of Web applications; and #2: enforcement. For the first issue, this option encouraged a lot of companies to just install a WAF and get compliant without going through a rigorous process of assessing applications. The actual requirement should be to assess all applications on a regular basis and either fix the critical vulnerabilities or use a WAF to block until those are fixed. In other words, you need both. As far as the second issue goes, enforcement is supposed to be done by the five credit card companies (American Express, Discover Financial Services, JCB International, MasterCard Worldwide and Visa Inc.) through acquiring banks. But enforcement of these standards have been focused on only the big merchants leaving millions of non-compliant merchants with insecure Web applications.
In addition to these, there are a number of other regulations like SOX, California SB 1386 and AB 1950, Massachusetts Data Privacy Laws, and many others. Most of these are at a much higher level in terms of data breaches and consumer information protection. None of these specifically go into Web application security issues.
So, what does this all mean? Do we really need more regulations? While too many regulations can be bureaucratic and costly to administer, sometimes you have no choice. Desperate situations require desperate measures. With over 75 percent of attacks occurring through the Web application layer, more emphasis needs to be placed on protecting this infrastructure. As billions of users are going on the Internet and shopping or entering their personal information into these websites, most of which are insecure, it’s only a matter of time before their information will be stolen. Our critical defense infrastructure and intellectual property is also susceptible to major cyber war types of attacks which have been occurring on a regular frequency now. For smaller merchants, we should provide tax incentives and loans to encourage them to protect their websites. We don’t necessarily need another new regulation but it’s time to update all the old standards to provide more clarity and enforcement guidelines around protecting Web infrastructure. Before it’s too late.
