How Involved Should a Developer Be in Designing a Security Policy?

Question

I've been developing software for well over 20 years. During that time I've worked in Fortune 100 companies that had very specific security requirements developed by dedicated security professionals and tiny companies with no concept of security requirements whatsoever.

It seems to me that very often, the majority of the time even, the de facto security policy ends up being created almost incidentally by programmers and tightly integrated into the finished product. Most businesses seem to just buy something and use whatever the default/hardcoded rules are without further consideration.

My question is, in a perfect world what should the role of an enterprise application developer be in determining security policy for their software? Should a product implement ironclad "best practice" or focus on being configurable and allow the consuming company/organization to determine their own policy?

(I'm talking here about things like if and when two-factor authentication is required, password complexity requirements and how long timeouts are and how many bad passwords can be entered before a lockout.)

EDIT:

OK, just to reiterate, I'm not talking about actual vulnerabilities like XSS or SQL injection, but policy. Suppose for an example that I didn't know how long a password needed to be in order to be sufficiently secure for my context and I'm only allowed a few hours to work on the minimum password length code. Am I better off researching how long is long enough and hard coding my decision or writing code that let's the admin customize it themselves?

Answer 1

I'm also a developer, and my passion for security often makes the dynamic a little unusual when dealing with other non-security-focused developers.

There are three main areas of constraint when it comes to security policy:

• Usability: Making sure that the user can actually use the software, and that they don't get overly irritated or delayed by security measures.
• Technical: Making sure than security mechanisms are properly implemented, and that they don't affect uptime, maintainability, or other critical technical factors.
• Financial: Making sure that the security measures don't cost too much, whether it be through direct financial costs (e.g. buying black boxes with blinky lights) or additional man-hours.

Your job should involve advising on the technical factors, and suggesting ways that you might mitigate any usability impacts. However, you should almost always defer to the technical judgement of a competent security consultant (competent being the operative word) if they disagree with you on a technical security matter. It's your job to integrate the necessities into a product in an optimal fashion, whilst overcoming the difficult hurdles.

In terms of direct involvement in security policy for software development, it largely depends on:

• Whether you have a dedicated security person or team.
• What sector you work in (means you might need to deal with PII or HIPAA data)
• Where you are in the organisation, and whether you're in a position to effect change.
• How security-focused the company is.

The interesting part of this question comes when you consider that most software organisations don't have a dedicated security person, let alone department. Regardless of whether or not your company does, you have a duty to learn about the types of security issues and mechanisms that apply to your work. If your company doesn't have a "security guy", that responsibility is even greater. Part of your job is to implement working and reliable software, which includes security, but another part involves relaying technical information to management in a way that they can understand. You can't do that effectively unless you understand the issues at hand.

In short, there's no simple answer. You're required to make some security decisions and implement certain mechanisms as part of your job, because that's what a developer does. As for how far you go, it entirely depends on you as a person and the organisation you work in. In order to make reasonable judgements when no overriding directive is provided, you need to put in the work to understand the issues.

Answer 2

I am all in favor of pushing people to better security standards, however I like to control my own destiny. My preference would be for you to develop options to give administrators the flexibility to make their own choices, but set the defaults to a high security level. That way if someone takes an interest they can make things conform to their own internal security policy, and if they use it out of the box then it has high standards.

Answer 3

IMO, Even in a "perfect world" a programmer should be involved. The programmer should be knowledgeable enough to translate business requirements and security lingo into developer-speak and vice/versa.

Put simply, only a developer understands exactly how the software works, and it's possible that something got "lost in translation". At the very minimum, a developer (or code reviewer - someone familiar with the actual code) should sit in and ensure that the people making the policies aren't doing so out of a misunderstanding of how something is implemented under the hood.

Not only does it help to make sure the others on the team understand and avoid mistakes, instituting such a policy/strategy helps to ensure that the programmer is fully vested in the security of his system. They just don't teach secure coding practices the way they should. Schools, or online tutorials all start out by showing you how to do things, and there's so much to learn that they seldom bother with how not to do things.

Every single security flaw in the IT world is the result of software somewhere. At the operating system level, in APIs that you're calling, your own code, somewhere there's a flaw that's allowing the bad behavior to happen. It could be a bug in the code, or a foolish requirement, but even poor requirements are flaws in the code that's built to the specification of those requirements.

So it makes sense to make sure that developers are involved - to get them thinking about security, and to ensure there are no misunderstandings that would lead to problems.

Answer 4

As a developer I'd say that it's up to the end user to define what the security requirements of the product should be. They should be the ones best place to understand the threat landscape that they face, and the risks that they have to deal with.

That said... you are unlikely to find a perfect customer that will know straight away their security requirement, at which point you're looking towards business analysts (which may well include developers, particularly architect with a deep understanding of the product) to help derive those requirements.

From a developer point of view knowing the best way to implement those requirements is going to be the key. And, just as important, knowing how to write secure software, the last thing you need is a buffer overflow/SQL injection that breaks all those nice requirements and design.

In terms of security configurability I'd subscribe to the secure by default mentality, such that it is deployed as securely as possible with the option to relax those security controls as necessary.

Answer 5

As a software architect and security professional, my thought on this is that while it is critical for developers to have a security focused mindset to design high quality secure software, the configuration ultimately needs to be up to the business needs of the end company or user. Software should be designed in such a way as to safeguard against malicious behavior and to support as rigorous of a security system as is expected to be needed, but security is also a balancing act between the need for usability and the need for security. As the developer, it often isn't possible for us to make the best decision as to the exact configuration details that will best meet the needs of whatever company or user ends up using the product.

This answer changes if you are designing software for in-house use and the necessary level of security is known prior to implementing the software of course, though having the ability to adjust the configuration later is still not necessarily a bad thing if it doesn't cause risk of further security holes through excess complexity.

Answer 6

I wrote a few baselines for a client, one of the most important things to do is to make sure the people who will implement it are also involved in the creation. Regardless if they are developers or administrators,... there should be a (partial) similar security policy, especially when it comes to passwords.

When you involve them you will:

• Get input and issues they regularly face, in this way you can easily define the scope, give them new insights and help them solve the issues from a security perspective
• They see it a little as their own project and they will adopt and accept the policy more easily
• If they have questions, they will ask them a lot faster and you can give them advice
• Because they accept and understand why you are making a security policy they might even promote or request for similar security projects more easily

Answer 7

In a perfect world your team / company would follow guidelines like the secure development lifecycle, combined with further restrictions depending on your field of work (influenced by law / compliance restrictions a.e.).

If you take a look here: http://www.microsoft.com/security/sdl/discover/implementation.aspx you'll see on a very technical basis where all you COULD be involved in.

We usually have the Scrum Masters oversee the implementation of these guidelines and collect feedback from the devs. But that's probably not the "perfect world solution".

To go with your example of the password: The guy responsible to oversee the implementation of the security policy would tell you / your team lead / the product owner, that the password has to have 16 alpha numericals and check back to see if it was implemented. It's definitely not your job to do research on this (perfect world). He'd have an awful long list of these things, actually :)