Networking/infrastructure specialists often have a very different view to developers when it comes to security. To be quite frank, the network guys have a very good track record these days (setting up firewalls, locking down servers etc.). The developers, being relatively new to the game, are having to play catch up at a time when many malicious users have discovered the vulnerabilities within web application code (such as SQL injection, cross-site scripting).

It's difficult for developers because there are very few tools or standard configurations that can lock down the application. A developer has to ensure that each function written has the necessary layers of security. For instance, has the input been validated? Is the database being accessed securely via stored procedures when adding the data to the database? Has the user been authenticated somewhere on the web page?

The two points of view (infrastructure specialist and developer) sometimes lead to conflict due to misunderstanding.

A case in point is the use of service accounts. The infrastructure specialist is often, but not always, keen for the logged on user to be identified and authorised by the operating system in all components of the application, by flowing the identity. This can be achieved via kerberos, or simply re-supplying cached credentials to re-authenticate (IIS and its use of NTLM is a good example of this).

The developer sees this quite differently. By flowing the identity to the database, a new security context is used each time. This means that connection pooling (several instances using one database connection, that is retained between batches) is lost, and so performance grinds to a snail's pace very quickly. Also, if one is authenticating and authorising the caller at the database, then that user has direct rights to the database, and can access it without going through the application.

This is why internet facing web sites generally use an application service account. The web server authenticates the user. The web application then uses that identity for checking whether the user can access specific functionality. However, it does not run under the context of that user - it functions under contect of the service account. Only that service account is granted access to the database.

Although this improves performance and prevents users accessing the database directly, there are certain vulnerabilities that have to be controlled. Firstly, this service account has very high levels of access to the database. Compromise of the application can give a lot of potential pwoer to a malicious user. To control this, it's important that secure coding practices are used. Also, tools such as Code Access Security, which restrict what each component of the application can do, mitigate the potential damage. As well as this, the database access should be locked down as much as possible. Never give service accounts dbo or sysadmin privilege. It's always best to give execute permission to stored procedures only.

Secondly, accounting and auditing is reduced. The operating system will log that every operation was performed by the service account. This is where a lot of 'plumbing' has to be coded. Usernames have to be passed to stored procedures, history tables have to be created, database columns with the name 'created by' are added to almost all tables. This can, and usually is, tightly managed.

Architecture guides, such as the ones produced by SUN and Microsoft, give a good overview of the risks, architectural patterns, and implementations that will satisfy security requirements:
http://msdn.microsoft.com/en-us/library/aa302415.aspx
http://www.sun.com/security/index.jsp

Another Google tool where you may be exposing your data across the internet, and have no control over where/how it's stored:

http://www.guardian.co.uk/technology/2009/jan/25/google-drive-gdrive-internet

How are they storing your data? Will it be encrypted? Doubtful, as this will slow down performance.

You're handing over your personal data to another company. In another country.

It was tried ten years ago, and never took off.

The private sector are the biggest users of PCs. Business will not use this, as they have to meet their legal and compliance responsibilities. That's why it ain't gonna fly.

Rant over.

The US National Security Agency helped put together a list of the 25 most dangerous coding mistakes.

 

Here they are, in all their glory:

Improper Input Validation

Improper Encoding or Escaping of Output

Failure to Preserve SQL Query Structure

Failure to Preserve Web Page Structure

Failure to Preserve OS Command Structure

Cleartext Transmission of Sensitive Information

Cross-Site Request Forgery

Race Condition

Error Message Information Leak

Failure to Constrain Operations within the Bounds of a Memory Buffer

External Control of Critical State Data

External Control of File Name or Path

Untrusted Search Path

Failure to Control Generation of Code

Download of Code Without Integrity Check

Improper Resource Shutdown or Release

Improper Initialization

Incorrect Calculation

Improper Access Control

Use of a Broken or Risky Cryptographic Algorithm

Hard-Coded Password

Insecure Permission Assignment for Critical Resource

Use of Insufficiently Random Values

Execution with Unnecessary Privileges

Client-Side Enforcement of Server-Side Security

Looking down the list, we can see that a number of the issues have been around for a long time. SQL injection – why are web sites still allowing this, after all the publicity and information disseminated on prevention? Many large organisations are still suffering from these problems, so it isn’t just confined to smaller businesses.

 

Most of the flaws come into being during implementation (development), such as:

Injection attacks

Improper file access

Some occur during design, such as:

Poor authentication

Broken security 

And some occur during the deployment/testing period, such as excess privilege for web applications. This is usually a result of developers running as administrator on their machines, and finding that the application won’t run any other way when it’s installed onto the production server.

 

There are also other categroies and flaws in the list, but I'm not going to be exhaustive in covering it. I'm focusing on initiatives to improve the development process.

 

So where do we start in tackling this? The problem really is a good example of how we must look at security as a process, rather than just trying to find a quick fix.

 

Concrete solutions that I have been involved in at various organisations have included the following:

Secure coding requirements

Training programs

Penetration testing

Code inspection

Validation frameworks

 One generally has to target both .Net and Java, as large organisations will tend to use both.

 

Secure coding requirements seem to be continuously written over and over again at one organisation after another. A good basis for Microsoft products is the Building Secure Asp.Net Applications document, and Improving web application security This guidance can be used, with company specific guidance appended. Java documentation gives less of an integration overview, but this is because it will be more implementation specific. However, the Microsoft patterns are quite generic.

 

Once these documents are written, they will then feed into the development process, and end up being part of the specific non-functional requirements for the application.

 

Training programs are another essential part of the process. I have worked with a global client recently, creating a training program that was based on the secure coding requirements, and the processes involved in getting security sign-off. This training was computer based, so that all technology-based employees could learn how to integrate security.

 

Penetration testing may take place, depending on the criticality and vulnerability of the application. For instance, an internet facing application with extremely sensitive data would certainly need a pen test. This will usually reveal discrepancies, which then have to be prioritised and fixed. Let the development team know early on whether this will be necessary, as it will have to be budgeted for.

 

Code inspection can take many forms. An audit based approach, taking a sample and manually checking, is useful. Also, there are many code checking tools, such as CAT.Net.

 

From the cat.net code download site:

CAT.NET is a snap-in to the Visual Studio IDE that helps you identify security flaws within a managed code (C#, Visual Basic .NET, J#) application you are developing. It does so by scanning the binary and/or assembly of the application, and tracing the data flow among its statements, methods, and assemblies.

 

I’m planning to produce an article on this tool soon.

 

Finally, validation frameworks are becoming more popular. There are lots of types of invalid input, such as

Mistyped entry – simply something which is misspelled or wrongly formatted, such as a date

Broken business rules – Perhaps the email field for your external-facing web site needs more validation than just a regex to check the formatting. What if someone were to enter an internal email address, from within the organisation? This could perhaps be fraudulent.

Request manipulation – querystring manipulation to access the wrong data is common

Validation frameworks are libraries that are geared to checking for all of the above, and more, so that they can be plugged into an application, giving a reliable, tested implementation. They have to be lightweight (so that they don’t take up too much memory, especially in web applications) and efficient (many of the functions will be called repeatedly during a request). Unfortunately, due to the inability of .Net and Java to call each other’s libraries efficiently, two versions would have to be built and maintained.

 

The OWASP Enterprise Security API (ESAPI) Project is an attempt to produce a strong security framework. The ESAPI is the result of over a decade of code review and penetration testing of critical enterprise applications. At present, only the Java version is available. Efforts to build ESAPI in .NET and PHP are already underway.

 

Hopefully, this article will give you some clues where to start when introducing an application-level security regime to your organisation.

 

I've just had a piece published by the nextgenug on SQL Server encryption, which is an expansion of my previous post. Hope you find this useful.

A major problem in the commercial world is getting people to look after their data. Too often, a staff member will save sensitive data in a document without adequate protection, bypassing all logical controls set up by the system administrator.

 

How do we solve this? Ask everyone to apply strong Access Control Lists to all data that they save? This would cause problems:

-A lot of wasted effort if the data is not sensitive

-For the sensitive data, how should one apply the ACLs? Which people should be allowed to access it?

 

A common solution has been to use the concepts of security classification from the defence world.

 

You’ll recall all those documents in James Bond movies marked ‘Top Secret’ and ‘For Your Eyes Only’. Well, this can be applied to the different types of data in an organisation. You can make up your own labels, but I’ll use these four:

Top Secret	-Could harm organisation if made public -Secret keys -Take over plans	-Store encrypted -Backup encrypted -Transmit encrypted
Secret	-Board meeting minutes -High value contracts	-Transmit encrypted -Backup encrypted
Restricted	-Low value contracts	-Transmit encrypted
Public	-All other material	-Unprotected

 

Now we have this, we can decide what type of data falls into each classification:

Top Secret	-Could harm organisation if made public -Secret keys -Take over plans	-Store encrypted -Backup encrypted -Transmit encrypted
Secret	-Board meeting minutes -High value contracts	-Transmit encrypted -Backup encrypted
Restricted	-Low value contracts	-Transmit encrypted
Public	-All other material	-Unprotected

 

This enables staff to know how to categorise data.

 

Now we add details of how the data is to be protected:

Top Secret	-Could harm organisation if made public -Secret keys -Take over plans	-Store encrypted -Backup encrypted -Transmit encrypted
Secret	-Board meeting minutes -High value contracts	-Transmit encrypted -Backup encrypted
Restricted	-Low value contracts	-Transmit encrypted
Public	-All other material	-Unprotected

 

So now staff can see how to handle each type of data. The table above would probably be a lot larger for most organisations, but you get the point. Staff can now identify the type of data, and from that they are able to use the correct safeguards.

 

Encryption of sensitive data at rest and in backups is very common for major institutions. This can be a very computationally intensive and difficult to implement control.

 

SQL Server 2008 introduces a new tool called Transparent Data Encryption. This encrypts data at the page level of the database, but decrypts it as it is read into memory. And it doesn’t increase the size of the database!

 

The encryption is performed by a database encryption key (DEK). This is a symmetric key, which is then encrypted by a certificate stored in the master database of the server. This is then protected using the DPAPI.

 

The following slide from MSDN makes things a little clearer.

 

 

This is great news for those of us who work in compliance related positions, such as security consultancy. A lot of effort has previously gone into development of solutions or selection of third party tools that provide this protection. Now SQL database administrators can provide this with minimal financial cost to the organisation.