There are no new excuses

There are a lot of reasons to do Static Source Code Analysis, and not many not to do it. Often there is no real understanding within organisations as to why Static Source Code Analysis is important, and a number of possible excuses come to the fore. We have heard most of these before, and most of them don’t actually stack up once there is an understanding of the reality of the situation. Have you heard…?

But the ops team look after that

Do you KNOW that they appropriately take care of security, or do you just BELIEVE that? Unfortunately in today’s environment, blind faith doesn’t cut it. At the end of the day, Management and the Board have overall accountability for security, and need to have an understanding of real risks.

But its not in the scope

Hackers don’t care that it is not in the scope. Attacks will come, irrespective of whether security is scoped in or not, so scope it in! With the increased scrutiny on business to take “reasonable care” in developing secure systems, there is no excuse for not “scoping” security in.

But a third party looks after that

Prove it. Most third parties, while they have a high degree of interest in customer satisfaction, are also revenue and profit driven. If they are not accountable, they may have different views on what is “acceptable risk”. Check your contracts.

But a third party developed that

They may be responsible for implementing security, but YOU are ultimately accountable. Outsourcing to third parties for development is an effective way of managing cost and development, however there is still an onus to account for the levels of security they either have or have not implemented.

But it’s a legacy system

The biggest issue being that it may not be supportable. Unfortunately bad guys don’t care about that. Legacy systems are often the main vector of successful attacks, as the security of the legacy systems are not maintained during transition to new systems. Vulnerabilities and exploits are always being developed, while your legacy systems are sitting still.

But it was secure when we deployed it

And your point is? New exploits and vulnerabilities are being discovered daily. Security of web systems is a dynamic process, not a “one off” exercise performed when the system is first deployed.

But it’s too critical to patch

If it’s that critical, it should be patched! The more critical a system is, the higher the value and hence the risk of the system being affected by malicious activity. All systems need to be kept up to date as much as possible against attack.

But if we patch, we break warranty

A sticky one. We have seen systems where the warranty would be broken by applying security fixes / patches, in which case the contract / vendor needs to be critically reviewed. If you can’t fix the system, complementary controls can however be applied.

But there’s no budget

Is there a budget for reputational damage, loss of customers, loss of revenue, contingent liability, etc? Whether you like it or not, an insecure system, deployed on the Internet, will be attacked and compromised to some extent. The cost of recovery is a lot more than the cost of doing it right up front.

But we’ve got a firewall

Firewalls are a part of a defence in depth strategy, but are not a panacea for poor security in other areas, and are an example of reactive security vs proactive security. Firewalls should be part of your first line of defence, not your only line of defence. If your systems are secure in the first instance, your firewall becomes a bastion in the overall defence in depth strategy, and become a lot more useful in managing and controlling traffic.

But our developers know how to code securely

Prove it. Show me the certifications in secure programming. There is a high degree of “faith” in the ability of programmers to develop secure systems. You already perform (or should perform) other forms of testing for audit, performance, reliability, business logic, why not test security as well?

Also, does every developer have the same level of quality in coding? Automation of source code analysis for security issues is a great method for improving the overall team development quality.

But we have to go live

Understand that, but bad guys need to make a living too. Deploying systems for expediency is a great way to be attacked and hacked. If you are going to go live anyway, deploy as many complementary controls as you can to reduce the impact of being hacked. The attacks are going to come anyway, irrespective of your go live strategy…

But our customers don’t ask for it

And? Contracting out of liability on the basis that customers don’t ask for security is not a great approach. There is an (unspoken) expectation of customers that their sites will be secure, whether they ask for it or not. Failure to do so is a great way to lose future business, not to mention potential liability for failing to take “adequate precautions” and “reasonable practice” when building stuff for customers.

But it’s only a proof of concept

Yeah, it’s also only stage 1 of a 4 year project, and we will bolt in security in stage 3. If we have any budget left for this, as the business plan had all the benefits identified in stages 1 and 2.
There seems to be an “accepted” business model called “prototype into production”. Whether this happens by stealth or by design, we have lost track of the number of times we have seen Proof of Concept systems deployed without regard to supportability, support, operational maintainability, security, etc, etc…

But nobody knows about it

Are you sure about that? Systems don’t need to be advertised in order to be attacked. Current attack tools use advanced randomization, fuzzing techniques, or block scanning to find systems. You do not need to be a “known” target in order to be attacked. If it is out there, it will be found.

But we’ve hidden it

From who? To what level? You may have hidden it from the average script kiddie attacker, but what about full scale automated attacks, and determined attackers? What level of assurance testing has been undertaken to Prove that it is hidden?

But it’s really hard to change

And your point is? The bad guys don’t care if this is an issue for you or not. If you REALLY can’t change it, at least put in place as many mitigating or complementary controls as possible, until such time as you can change it.

But it’s on the way out

It’s always a bit difficult to justify spend on systems that are reaching end of life. However, if there is a vulnerability, and it is exposed, it will eventually be attacked. The world will change, and new attacks will occur, while you are diligently moving to a new solution and avoiding addressing the “right now” state.

But it’s an interim system / solution

This is a common one. How many of us have deployed interim systems, only to find that they tend to be there for years, due to the benefits apparently outweighing the justification for replacing it with an engineered solution over time? Interim solutions need security care and love as much as fully engineered solutions. Sometimes more, due to the rapid deployment often not addressing the security concerns.

But it’s standards compliant

Compliance is not security, although it can be a useful precursor. Just because it is standards compliant, doesn’t actually mean that it is secure, or that your obligations stop at that point. Compliance standards are useful in establishing a “minimal level” of capability, however often the emphasis is on the audit “check list” rather than actually addressing the real state of security.

But the cost benefit is not there

Have you considered the reputational damage if you are hit? The potential litigation issues around class action for failing to take reasonable care? The REAL cost of recovery if you are hit? Most cost benefit analysis around web applications is light weight, and do not adequately address the real world costs if things go bad.

But we don’t think hackers could find that

They can. They do.

But we can’t explain the risk to the bosses

Get a security consultant or a CISO to help with the articulation. A lot of bosses don’t understand the technical issues or technical discussions, and it does need someone that can translate the technical issues into real business risk. Business people understand business risk. Translate it into those terms, and it is more likely that they will “get it”.

But we have other priorities

If you do get hacked, what would that do to your priorities then? Really, the addressing security BEFORE the fact is the most cost effective way to do business. This has been proven in a number of studies, most of which indicate that it is 30 times more expensive to address when you get hit, than doing it right up front. Do you need to reassess your priorities?

But it’s an internal system only

Internal systems get hacked too. Malicious employees anecdotally cause more problems than external hackers, and secondly, once an attacker gets into the environment, an insecure system is one of the best ways to continue the assault.

But we contracted out the risk

You can contract out responsibility but not accountability. If you get hit, you still get hit, irrespective of whether and what you contracted out to another third party. Secondly, if legal action is taken, it will be against you first, and for you to tackle the third party contract. Do you really want that? Expect the best, and assume the worst, don’t take “contracted” security at face value as you have the overall accountability. Hold the third parties to account, and measure what they actually deliver.

But we did a risk assessment

What methods? What standards? To what extent did the people performing the risk assessment have the expertise to understand all threat and attack vectors? This is a fast moving field, and “checking the experts” is prudent to ensure that the Risk Assessment was performed adequately.

Secondly, check for a disconnect between the Risk Assessment and Risk Management plan. It is often the implementation of risk controls (technical, people, and process) that fails to adequately or appropriately address the risk.

But it’s in the cloud, they will look after it

Cloud computing is an emerging field, and as such, the risks are emerging and evolving as well. Add to this the lack of appropriate standards across all the players, and assuming that “putting it in the cloud” becomes a potentially risky situation. Accountability unfortunately can’t be sent into the “cloud”, so address security yourself.

But there’s no business justification

This is pretty common. IF, after a structured and accurate risk assessment has been carried out, AND you have clearly identified the value of your information assets (and your customers assets), AND the potential impacts have been ratified and identified as not business affecting, AND you are prepared to carry the risk of not only being hacked yourself, but becoming a contingent liability partner in your systems attacking others, AND you have a massive hedge fund to deal with any claims / investigations, THEN by all means accept the risk.

But we just expect our outsourcers to put in security

Expect security, assume nothing. Outsourcers are also driven by returning value to shareholders, while maintaining healthy relationships with their customers. However don’t assume that they will “just put in security”. It doesn’t happen. Unless you specifically ask for it, measure it, and pay for it.

But it’s not in the contract

“we disavow any warranty or liability around the fitness for purpose, being free from any malicious code, or being secure against attack”. Check your contracts for software, services, outsourcing, etc. Hold your suppliers liable, and don’t blithely accept “check and forget” contract terms. You are accountable at the end of the day, ensure that you pass on some of the risk to your own suppliers.

But we did some encryption

AES is secure. Most implementations are not. 90% of all implementations can be bypassed, intercepted, or generally broken by attackers, including taking advantages of other vulnerabilities to access keys, in which case the quality of the encryption algorithm is somewhat irrelevant. If your system is vulnerable, the likelihood that your encryption is compromised is high.

But we don’t think it’s a risk

We do. Not “thinking” it is a risk does not make it so. If you don’t do a reasonable level of “due diligence” around a risk, and it happens, there may be consequences. Don’t “think” it’s not a risk, prove it first.

But we think we can live with it

I am sure that there are a number of companies (no longer in business) that also thought that. Prove it, and get a signature from your CEO that says he will live with it. Don’t be surprised if he / she decides not to put his signature on the risk acceptance.

But I don’t want to lift that rock

This is no longer a viable defence; under most legislation and company law, companies are obligated to understand their issues to a “reasonable” level. “What I don’t know can’t hurt me” is likely to hurt you. With more focus on liability starting to come through the industry, liability is there, irrespective of whether you lift the rock or not. If you at least lift the rock, the opportunity for surprises

But we aren’t liable

Actually, you are. Under various legislation, company law, contractual law and contracts, the degree of liability ranges from financial penalties, through to class action, through to jail time.

But someone else has tested it

Do you trust the people that tested it? To what level? Was the value of the system and risk sufficiently defined to qualify the level of testing undertaken? Remember that every system on the internet is attackable to more or less the same degree. The extent to which these succeed is due to the complexity of the system, the focus of the attack, and the level of assurance that the systems have adequate levels of security.

But we had accountants audit it

Ok, hard to argue against that one, isn’t it? </facetious>

But it meets PCI requirements

See Standards Compliant

But there’s no money to fix it

Is there money to recover from a successful attack? The cost to resolve issues BEFORE they become a real problem has been proven to be at least an order of magnitude cheaper. Do you actually KNOW the real value of what you are protecting, and the costs of not fixing it to the point that it becomes a problem?

But we have a development methodology

Does Security have a specific fit in the development methodology? Do you start with a security risk assessment at the same time as you do the business risk assessment? Are you following emerging methodologies such as Microsoft SDL? If you don’t specifically address security somewhere in your methodology (including design, development, testing and assurance), then you don’t have a complete methodology.

But it’s never been a problem in the past

It will be in the future. Probably sooner rather than later. In Internet terms, yesterday is history, and tomorrow is an unknown and emerging future. What worked yesterday is now irrelevant with the constantly emerging threats and attacks.

But we don’t believe it will happen here

It probably already has to a greater or lesser extent. We are no longer surprised at the number of customers who couldn’t detect that an attack had taken place, or that their systems were compromised. Most detection has actually been through the hacker accidentally causing some form of unexpected system behavior, which is then noticed.
Add to this the lack of standardized reporting of attacks, and there are a heck of a lot more successful attacks that take place than are publicized, and the costs of these are way under reported

But it’s not cost competitive to do it

Accepted that release cycles, speed to market, price sensitivity, etc. are significant issues that need to be overcome. However the cost of being caught and publicized as having an insecure system or release can be either a deal breaker, open yourself to liability, or be the end of your company in its current form. This happens.

But it’s not worth spending the money on protecting it

Maybe not on protecting “it”, but have you considered ALL the areas that could cost you money if it all goes wrong? “it” may be not worth protecting, but your systems, reputation, and protection against litigation / liability certainly may be.

But we have antivirus tools on the server

<facetious comment> yeah right, that’s all you need </facetious comment>.

As a PART of your overall defense in depth strategy, fine. But don’t rely on these tools as the “be all and end all” of security. A proactive stance towards security of ensuring your systems are all secure is better than a solely reactive stance of hoping your defensive systems (AV / Firewall, etc) are going to be 100% effective.

But we don’t understand the risk

So find out! There is an absolute wealth of information out there, some by vendors, some by professionals, some by the industry. Everyone (except the really bad guys) wants to help you get secure, and to help you understand the risk. The plethora of information out there is more than sufficient to understand the risk to whatever level you are prepared to go to.

Got one we haven’t heard?

Then tell us! We’d love to respond. The best excuse between now and May 30 2010 (just over a month from now) will win a free CodeScan License in the language of your choice. Either comment below, or tweet us – @CodeScanDev

We’ve been hard at work at CodeScan Labs preparing for this; and it’s finally here!  A version of CodeScan which integrates fully into Visual Studio – allowing you to scan your ASP.NET C# projects and mitigate potential vulnerabilities as they are implemented rather than as a post-development step.

CodeScan for Visual Studio is fully compatible with Visual Studio 2005, 2008 and 2010 – and is fully integrated into the Visual Studio environment.  You can kick off a scan within your current project, and all results are displayed through the Visual Studio Editor.  This really simplifies the process of identifying and mitigating potential vulnerabilities.  All of the functionality that was previously available within CodeScan Developer has been ported across – and it’s ready to download now.

But that’s not all we’ve been up to.  We’ve also squeezed some new features in that aren’t available in CodeScan Developer yet (watch this space!) – but are available in CodeScan for Visual Studio right now!

• Additional detection routines in ASP.NET C#
• Advanced Reporting Categories – Provide reports against industry standards, such as
  • OWASP Top Ten 2007 and 2010 RC1
  • Application Security Verification Standard (ASVS) Level 1 B
  • Common Weakness Enumeration (CWE)
• XML Reporting Output

The XML Reporting Output will allow you to integrate the results generated by CodeScan into your own systems; such as bug tracking systems and custom reporting.  The XML Documentation will be available very soon, so watch this space.  We will be implementing this format for XML Reporting in all future releases from CodeScan Labs – including CodeScan Developer – so any tools you develop to read the CodeScan Output will be compatible with all CodeScan applications for the forseeable future.

This release has been a huge step for CodeScan, and it’s a step in the direction of “openness”.  There’s definitely more to come, and we’d love some feedback on the direction we’ve taken.  Is there something you would like to see implemented in a future release of CodeScan?  Let us know, and we’ll see what we can do!

To try CodeScan Visual Studio for free, sign up here.  We’ve also extended the free trial key -  it now includes absolutely everything for 7 days!  Full vulnerability coverage, full access to reporting – try it out, and get a feel for how CodeScan will work in your development environment.

The team at CodeScan Labs are pleased to announce the release of CodeScan Developer 1.9.0. This release is the second stage of our three phase release strategy for CodeScan Developer and features a shift to the .NET framework, as well as a hugely improved user interface, customization options and improved detection in all scanning languages, especially ASP.NET C#. Most importantly, the product has a highly improved level of stability and robustness.

The third stage of our release strategy will feature various improvements in reporting, including additional standards for reporting with CWE and OWASP.

It’s available for download through our members area – you can login or sign up from the buttons in the top right corner of this page.

Once you’re up and running, jump into our quick start guide.

As usual, we are looking to continue improving in the next releases of CodeScan Developer. We’re always keen to get some more feedback, so please feel free to contact us by Twitter (@CodeScanDev), our forums, email or comment on the blog.

We’ve also introduced a language bundle, which includes all three languages for only US$997 (a saving of US$394)!

If you have any questions, or would like to discuss your needs with one of our security experts, please email us at support@codescan.com

Cheers,
The CodeScan Labs Team

We are pleased to announce that CodeScan 1.8.5 is now available! It’s available for download through our members area- you can either login or sign up from the buttons in the top right of this page.

Once you’re up and runing, jump into our quick start guide.

We have been listening, and have significantly improved CodeScan’s user interface. Refreshing the display, simplifying the process so that you can now get up and running with your source code scanning projects much faster. This is a significant change, with new navigation, new display of the overall scan set up and reporting.

This new design makes CodeScan much more user friendly- and we’re looking to continue improving in the next releases. We’re always keen to get some more feedback, so please feel free to contact us, or comment on the blog.

Cheers,
The CodeScan Team

This post has been syndicated from Peter Benson’s personal blog, “From The Source”
Excellent! We are starting to get some nice feedback from our users, and also from the community, and as a result, we have started incorporating some of the feedback into new releases coming up over the next couple of months.

Already we are planning releasing a new class of vulns in our 1.8.4 release, Stored Cross Site Scripting. We are taking a slightly different approach to some of the others in the space at the moment, and really expect to have both accurate detection, and a great reduction in false positives.

Also keep an eye out for a revised File Management screen, which will provide better usability for adding and managing files in Projects. This is a good win for us, and will make the management of projects (applications) within CodeScan a lot easier.

So we have had coverage last week in Computerworld, and good feedback / validation of approach through the Serendipity IT Ltd blog.

Keep the feedback and comments coming guys, the good, the bad, and the ugly. We’re here to build products for you guys, so the more the better. One free license each month for the best feedback!

It’s all good.

This post has been syndicated from Peter Benson’s personal blog, “From The Source”
This is the third in a series of where Source Code Scanning fits vs. Application Scanning. This time I’ll focus on Development vs. Operations.

One of the issues that I face on a daily basis is the attitude that web applications are “presumed” secure once they are developed, as a lot of people assume that their code is secure, even if large parts of their code are copied in from other sources. So the first real time that the application is exposed to security testing is when it goes into either a pre-production environment, or worst case, once it has gone live. Sometimes not even then.

Anecdotally, we have spent a lot of time working on open source software, including code that has been worked on by a lot of very knowledgeable people, and we are still finding interesting vulnerabilities. I know that a lot of implementations of these systems are not being tested when they go live, so it is likely that there are way too many untested and unproven web sites out there.

Seriously, the only way, and the most cost effective way, is to test your code while you are building systems, not waiting until the end (or never!). This way the code will be better, more secure, and costs a heck of a lot less than if someone finds your vulnerabilities once the system is out there and exposed.

Once your application has been deployed into either pre-production, or production, by all means use Application testing tools, and penetration testing, to prove the security of the deployed implementation. But this testing should be a back stop, and NOT the first time that security is actually addressed.

Oh yeah, if you then make changes to your web applications, either maintenance releases or new functionality, test your source code again. I get really concerned sometimes at the number of times a web site gets changed without being tested again. Security and exploits are also evolving, and what was secure last month is not necessarily secure this month. Either in operations or as a part of your regular release development, test your systems!

Operationally, layer your security with active management systems such as Firewalls and IDS, implement a vulnerability and configuration management system, and verify your security over time with application testing and manual penetration testing.

Want to be secure? The above is a lot more likely to both get you there, and to keep you there.

This post has been syndicated from Peter Benson’s personal blog, “From The Source”
I get asked a lot what the difference is between Application Scanners and Source Code Scanners. Mainly as there seems to be a lot of emphasis on what vulnerabilities are being looked at; the biggest example of this at the moment is the plethora of various products found if you do a search for SQL Injection scanners / protection.

This is the second in a series of posts, which will help to identify where each type of product fits best. In this post, I will explore the notions of black box vs white box testing.

Firstly the definitions:

Black box testing takes an external perspective of the test object to derive test cases. These tests can be functional or non-functional, though usually functional. The test designer selects valid and invalid inputs and determines the correct output. There is no knowledge of the test object’s internal structure.

This method of test design is applicable to all levels of software testing: unit, integration, functional testing, system and acceptance. The higher the level, and hence the bigger and more complex the box, often the more one is forced to use black box testing to simplify. While this method can uncover unimplemented parts of the specification, it is really difficult to be sure that all existent paths are tested.

White box testing on the other hand, uses an internal perspective of the system to design test cases based on internal structure, and is based on a level of knowledge. While white box testing is applicable at the unit, integration and system levels of the software testing process, it is typically applied to the unit. While it normally tests paths within a unit, it can also test paths between units during integration, and between subsystems during a system level test.

Though this method of test design can uncover an overwhelming number of test cases, it might not detect unimplemented parts of the specification or missing requirements, but one can be sure that all paths through the test object are tested.

Application Scanning vs Source Code Scanning

Application Scanning is generally considered to be “black box” oriented, as the scanning is done against an object or system without a high level of knowledge, and there is a requirement by the tools to be able to interpolate a level of knowledge as to what it is testing against to determine the level of testing involved. As the testing involves both valid and invalid inputs and qualifying the output this is can sometimes be risky in production environments. Generally systems will be sufficiently robust to not fail under this level of testing, however it is a risk that needs to be considered when testing anything in a production environment.

Application Scanners can also often work in a partial “black box” environment, where often credentials are required to be provided to the scanner in order to test or access functions that are not immediately visible to the scanners.

The best way to look at application scanners, is that they are largely black box oriented, and can only test what they find / see / discover. Their advantages are that (in a production environment) testing can be performed from anywhere, and the testing is based on what is essentially a “user experience” based analysis.

 Source code scanners on the other hand, are very white box oriented. While earlier source code scanners required a high level of programming knowledge to set up the various tests, the new generations of source code scanners will operate with a minimum level of programming knowledge; more often than not, requiring that the operator understand the structure of the overall application being tested. From there, the source code scanner should be able to identify and “read” the code, and apply testing as appropriate against the code base.

The big advantage here is that the overall (total) application code can be tested, as all the code is supplied. Combinations and object interactions can be tracked and measured, and there is no requirement to access one level before testing the next level. The testing of the code is very comprehensive. The main disadvantages of the Source Code “white box” approach are that often the configuration of the operating system / server that the application is run on may not be tested in conjunction with the code base, and secondly (not a big disadvantage if done properly), it is a “pure” test, and not necessarily reflective of what an external attacker would see.

Summary:

Both levels of testing have their place in a full defence in depth strategy, where black (or semi-black) box testing using application scanners are used in both the pre-production and production environments to simulate attacks as they would be undertaken by an attacker. Can be run from almost anywhere, and can be run relatively easily. Generally only tests what it can see or discover through initial analysis, however has a strong position in operational testing.

Source Code Scanners on the other hand have the advantage that ALL source code associated with an application can be tested, and can be tested from the first line of code that is cut by developers, through to the point that the application is deployed. Also, any time that the code is updated, refreshed, maintained, or new exploit methods are discovered, the source code can be rescanned before committing the application to the world.

This post has been syndicated from Peter Benson’s personal blog, “From The Source”
I get asked a lot what the difference is between Application Scanners and Source Code Scanners. Mainly as there seems to be a lot of emphasis on what vulnerabilities are being looked at; the biggest example of this at the moment is the plethora of various products found if you do a search for SQL Injection scanners / protection.

Generally it can be considered that Application or Code scanners perform reasonably similar functions, and there is a place for both. A reasonable defence in depth strategy has a number of tiers of protection, and both types of scanners play a part in the overall control of security within a company.

While I will discuss a number of other differences over time, the primary difference that interests me is:

“We should be developing secure applications from the outset”. Source code scanners, that are used during the development lifecycle, are a primary means whereby more secure applications are developed. Most application level scanners are really designed to be used in either pre-production, or production environments, and do not necessarily address the needs to test the development of your applications, as the code is being written.

Most security applications and controls are based on a Reactive approach to security , and are really compensating controls, i.e. compensating for issues that should not be occurring in the first place. Source Code Scanning is one of the primary tools that can be used to develop secure systems in the first instance.  Once systems have been developed, additional control mechanisms then come into their own, such as Firewalls, Intrusion Prevention Systems, Application Scanners, etc. Most of these either provide protection or assurance, which is definitely required, but I personally prefer proactive security mechanisms such as Source Code Scanning, so that a lot of the issues that we try to protect against, are dealt with before they become issues.

Its always better to build a secure house that stops mice from coming in, rather than trying to build a better mouse trap