Who owns security? [closed]

Question

I've been developing a multi-tier application using the following:

1. ASP.Net - UI Layer
2. WS - Business Service Layer
3. WS - Data Service Layer
4. SQL - Database Layer

Is the security the responsibility of the Architects, Developers or Infrastructure?

More specifically the security from layer to layer.

I guess the answer will be all of the above.

However, I'm just wondering what people's experiences are of it - especially working in a non-agile environment? Should everything be designed and security decided up front in the technical design document (not ideal I know)?

Answer 1

Let's face it, if security isn't owned by EVERYONE, then it will be owned by NO ONE. (I believe Ricky Bobby said that first).

The issue is a cultural one. Most organizations give great lip-service to security but do a poor job implementing it simply because they don't understand it well. When you consider how simple it can be to handle the top ten security vulnerabilities, it is inexcusable not to. Because it really is easy once you 'get it'.

Quick example:

Your sensitive app needs to be protected against packet sniffers like Fiddler. You must

1. Turn on SSL/TLS to protect it between the browser and the client. That's the responsibility of the UI layer you mentioned in the question.
2. Enable the WS-* stack between the web server and your business service layer. That is the responsibility of the business service layer guy.
3. Enable WS-Secure between the business service layer and the data layer. The data layer guy has to do that.
4. And you need to implement a service broker or use keys in the database. Here's a link for all that. That must be done by the DBA.
5. All of it needs to be coordinated by your manager and designed by your architect.

So you see, it MUST be done throughout the group and therefore must be a cultural topic, not just another box to be checked.

Hey, I feel your pain in getting this done. Props to you for raising the bar!

Answer 2

I will have to agree with everyone that security has to be a design/implementation concern shared by everyone and it must cross all of the layers. I work for a very large company working on very large internal web applications where everyone using the system is a trusted person, and security is still a top concern.

Here is how it breaks down on my web apps from a layer perspective. When a request is sent to the web application, there is company wide security at the sub-domain level which only only allows SSL (HTTPS) communication to the server. There is also another server (network appliance) that intercepts the requests to the application and will handle logging people into the application (authentication) based on the username and password and the URL they are going to.

When the request hits the UI layer, it runs through another security check to validate the user credentials and groups sent when the user logged in (authorization). This is to determine what actions the user can do in the system. In the business service layer we implement business security logic (using AOP) to filter out certain data that the user is not allowed to see (such as information about his/her self). This will allow the filtering to be done in one place even if it is being called by different places from the UI.

At the data access layer or SQL the company only allows stored procedures. This makes sure that the DBA is aware of all calls to the database (DBA is the only person who has access to make changes to the DB schema) and that none of the developers can sneak in bad SQL. To access the database we use a special user ID and a password that is encrypted in a config file (company policy and a FedRAMP requirement).

When the data comes back to the screen to displayed, we occasionally add a custom hash to some of the data that we do not want the user to tampered with.

Security is something that should be part standard for the company and part application specific. If your company has an architect, he/she will help you define where you need security in the different use cases and where you need to override the default security provided by the infrastructure / company. When it comes to the actual code it is the developer who generally figures out how implement the security in the specific flows and to find the flows that need the security as identified by the architect. After the application has been coded and setup (preferably in a staging or integration environment) you need someone from the application security team to test the application to make sure it functions as intended and there are no security flaws.

Let me know if this answers your question...

Answer 3

I'd say it is primarily the responsibility of the requirements. Only when you have a stated security requirement/policy can you implement and test it.

Whether it is the database layer depends on a few factors; security inside the database is possible, but tends to be expensive - by which I mean:

• less connection pooling if you use connection identity
• overheads if you have to encrypt the data/connection

But it is an option (albeit it one generally reserved for the most security-critical applications, where even DBAs aren't allowed to read the data); other than that... security is largely a cross-cutting concern. You'll certainly need a security implementation specific to the UI layer (since it is handling the cookies etc), but most of the work tends to be part of business logic.

Answer 4

The application needs to be designed with security in mind, furthermore it needs to be developed in a secure fashion. The initial responsibility falls on the system architects for designing the specifications, then it falls on the developers for implementing it properly (with oversight from the architects) and lastly the web server has to be secured from system administrators and/or infrastructure. The biggest issue is that often times developers in the middle layers assume everything that they are given from other components in the system will have been validated, this is generally not the case and can cause some hard to trace security holes. Therefore each layer must be developed as its own secure sandbox to prevent data leakage.