Executive Briefing: Security - Where do you stand?

Q: How do you know if your company's technology environment poses too much risk for you to continue in its investment, given the concerns of privacy and confidentiality that Internet business faces today?

A: The short answer is through calculated measurement and assessment of your current technology configurations against well defined policies procedures and/or standards.

For the long version its about revenues, reputation and regulation. First and foremost you need to take a look at your organization's assets. Where are the crown jewels? What are the things that you are trying to protect? This can be in the form of physical assets, such as product, or information assets like customer data. Secondly, most organizations care about their reputation in the industry as well. Ultimately, damage to your reputation can affect your revenues. How would a breach in the security controls protecting your valuable assets affect your reputation? How would a web site defacement, which may not necessarily affect valuable tangible company assets, affect your reputation? And last, what regulations apply to your company's line of business? You need a thorough understanding of what it is you are trying to protect and what the regulatory requirements are that impact your operation. Then the discussion turns into an exercise of risk management. What loss can be tolerated and what can not?

Q: So... How do we measure our technology configurations to assess their security posture?

A: The only way to effectively measure your security posture is through a human led team of security assessment professionals. Note that I used the term assessment. You can't get the result through a software product. You are not looking for a team of auditors or penetration testers. Auditors are good for looking at what you do, and perhaps do not do, based on your policies or external regulations. Typically, an audit is a very structured have or have-not process and it may not discover certain vulnerabilities in your organization's operation or technical configuration. On the other extreme, you have penetration testing which does look for vulnerabilities within your organization's operation or technical configuration. Quite often, the ultimate goal of pen-testing is to penetrate and demonstrate that unauthorized access to protected resources can be attained. Nine times out of ten you don't need high priced hackers to demonstrate that because your weak link will be your employees or the process they follow. Most importantly, you may not get a good feel of the true risk your organization carries if you don't focus on a well defined scope for pen-testers. However, there is clear value for both extremes. A security posture assessment conducted by a competent team will provide each of those extremes and blend other practices in the middle, like education, awareness and strategic development paths, to provide a useful result to executive leadership.

Fuzzing to help deploy secure applications

So, the practice of "Fuzzing" is starting to get more attention in the security world over the past few months. I recommend a read to keep in the loop and to stay sharp: Fuzzing: Brute Force Vulnerability Discovery. After reading it in it’s entirety, I think it will need to be on the shelf as part of any security professional’s library. I’m not a programmer, nor do I manage programmers directly, so I can’t speak to the direct impact the practice of “fuzzing” may or may not have on an application’s ultimate success. I do, however, speak to them regularly and I need to know this stuff even if it hurts my brain to be pouring over it, knowing that the chances of me actually using the tools or frameworks discussed in the book are slim to none. I can speak first handed from the vantage point of a CISO, it is essential that executives begin to understand not only what “fuzzing” is, but why we need it, and more importantly, where it fits in the evangelical world of information security.

HP/SPI Dynamics and Cenzic are friends... for now

After marriage, your spouse's family becomes your family, and oftentimes your spouse's family issues become your issues. Similar to marriage, when you acquire a company you also acquire any of their outstanding legal issues. HP and Cenzic have agreed to disagree but still share the potatoes at the dinner table. In case you haven't followed this one, it started in September 2006, when SPI Dynamics (now owned by HP) filed a lawsuit against Cenzic for allegedly violating its patent for a method for finding vulnerabilities titled "Internet security analysis system and process" (No. 6,996,845). Cenzic received its own patent for using fuzzing to find vulnerabilities, which was titled "Fault injection methods and apparatus" (No. 7185232) and granted in February 2007. Then subsequently, five months later, filed its own lawsuit for patent infringement against SPI Dynamics. Well, that has all been dropped. It's time to let bygones be bygones and plan for a good holiday home coming. (I think... something smells of PR and deep pockets here) I for one don't understand how you can patent a process like that which was in dispute. After searching around a little I found some resources who feel the same. In particular, remember the old @Stake crew? I can remember working with the folks at @Stake and talking about these methodologies sometime in 2001-2002, and I would venture to guess that the @Stake crew could voice their opinion on where this stuff came from. At least, in the early days of pen-testing for profit... Check out the next-gen @Stake crew's opinion on the Veracode blog.

Getting started: The OWASP Top 10 of 2007

The Open Web Application Security Project maintains a list of the most common web application security vulnerabilities. Understanding these vulnerability categories is the first step toward developing secure web applications. They are listed below from the most prevalent to the least prevalent found given a random sample of web applications.

Cross Site Scripting (XSS) : XSS flaws occur whenever an application takes user supplied data and sends it to a web browser without first validating or encoding that content. XSS allows attackers to execute script in the victim's browser which can hijack user sessions, deface web sites, possibly introduce worms, etc.

Injection Flaws: Injection flaws, particularly SQL injection, are common in web applications. Injection occurs when user-supplied data is sent to an interpreter as part of a command or query. The attacker's hostile data tricks the interpreter into executing unintended commands or changing data.

Malicious File Execution: Code vulnerable to remote file inclusion (RFI) allows attackers to include hostile code and data, resulting in devastating attacks, such as total server compromise. Malicious file execution attacks affect PHP, XML and any framework which accepts filenames or files from users.

Insecure Direct Object Reference: A direct object reference occurs when a developer exposes a reference to an internal implementation object, such as a file, directory, database record, or key, as a URL or form parameter. Attackers can manipulate those references to access other objects without authorization.

Cross Site Request Forgery (CSRF): A CSRF attack forces a logged-on victim's browser to send a pre-authenticated request to a vulnerable web application, which then forces the victim's browser to perform a hostile action to the benefit of the attacker. CSRF can be as powerful as the web application that it attacks.

Information Leakage and Improper Error Handling: Applications can unintentionally leak information about their configuration, internal workings, or violate privacy through a variety of application problems. Attackers use this weakness to steal sensitive data, or conduct more serious attacks.

Broken Authentication and Session Management: Account credentials and session tokens are often not properly protected. Attackers compromise passwords, keys, or authentication tokens to assume other users' identities.

Insecure Cryptographic Storage: Web applications rarely use cryptographic functions properly to protect data and credentials. Attackers use weakly protected data to conduct identity theft and other crimes, such as credit card fraud.

Insecure Communications: Applications frequently fail to encrypt network traffic when it is necessary to protect sensitive communications.

Failure to Restrict URL Access: Frequently, an application only protects sensitive functionality by preventing the display of links or URLs to unauthorized users. Attackers can use this weakness to access and perform unauthorized operations by accessing those URLs directly.