SDLC: Understanding your Roles

Application security should be on the mind of anyone that is part of the application design/build process. That means architects, developers, application owners, QA testers, business analysts and even end users. Everyone of these positions plays a role in the security of the applications. Depending on the organization, the roles can be quite different. You must understand the roles of these positions from a development perspective to really understand how they fit into the security aspect of the machine.

The first step in the process is to define and document each role in the SDLC. The goal is to understand each role’s relation to your SDLC. Usually the size of the development teams indicate the number of roles that may be implemented. Here are a few things to think about when you are defining your roles:

• Who defines business requirements – Often times the requirements get spread across different teams. Ideally it is the application owner and business analysts working with end users to determine the requirements. However, often times many items are left up to the developers or database administrators to determine or define requirements. This is especially true around input validation or how data is stored.
• Who directs the coding guidelines – In large enterprises it is common to see a centralized architecture group that defines coding guidelines across different teams. They may define if database access is limited to stored procedures or a specific ORM. In other situations it may be up to the individual developer. Is there a central input validation or output encoding framework?
• Who determines database schema – When thinking about how data is stored, who defines the fields that are used, how they are protected (encrypted, hashed, plain text) and how the database is structured? Does the table layout make sense? Is it properly segmented?
• Who tests the application – The quick response is the QA team, but developers are most likely responsible for testing as well. What about third parties, whether they be an internal security team, a client team or other 3rd party testing teams.

Understanding these roles and who is doing what is critical to maturing a secure SDLC program. Traditionally, the groups are often fairly separate, but as you start to look at the different questions you realize that many of these items are handled by multiple groups. It is that collaboration and communication that is also critical to maturing the SDLC.

The next step is to start identifying the people that are occupying these roles. What skillsets do they possess and do they line up with the role you just defined? This will ultimately lead to defining what training is required for each resource. Providing custom training that is specific to the groups needs is much more efficient and effective than just hosting a generic secure coding class. What if the group that needs training is QA or the business analysts? Developer training isn’t what is needed there. What if the group develops in .Net? A course written using Java will not be as effective.

Finally, we start to identify the processes for the SDLC from start to finish and look at what does and does not exist. From the processes that do exist, what role is responsible for that piece of the puzzle. There can be a lot of cogs in the development process, especially when we bring security into the picture. Think about things like static and dynamic analysis, which are part of most mature secure SDLCs. Do these exist, and if not, who will be the people involved with them when they are implemented?

Identifying the full process and what each role is doing is really the beginning of creating baselines for your program which we will cover in another post. This is critical because it provides a starting point so we can define where we are going. Like an asset inventory, you must understand the roles in the entire SDLC and what part they play. Once we start to truly understand our teams, we can start to make the adjustments needed to move forward in secure SDLC maturity.