Application Security Charter

Your foundation is laid and you know what, you’ve got an idea of what you’re going to do, and what you want out of your security program, you’ve got well defined founding principals (your pillars)

Now that you know that you’ve started to frame your security program and you’ve got the foundation in, it’s now time to start the next level of discussion within your security program. The Program charter is a fundamental document to the success of your program. The charter is going to be the constitution of the program, when you think back to how your country was built, some folks got together with some principal ideas (your pillars), they argued and debated them until there was a consensus, then they wrote the founding document, be it the Constitution, declaration of independence, or some other document. Now you are maybe thinking that you’ve never encountered the idea of a constitution or team/program charter anywhere else in your technological career, so why does a security program need one?

Application Security Charter

One of the biggest struggles that you’ll find, constantly within the lifespan of your program is that the work of a security program and/or a security team doesn’t “generate” revenue to the business, even though you’ve managed to get business approval and management approval, this question doesn’t go away. This question can be even further complicated if you already have an Information Security team, and you’re working specifically under application security program.

Typically, Information Security teams are very good at what they do but they lack the knowledge /skills of specific application security. This isn’t a knock against them. These teams are usually very busy looking at the whole organization and application security needs some very special expertise applied to it that InfoSec sometimes doesn’t have the time or the ability to provide.

The Security Charter will help you, and anyone else in your program or on your team in the following ways:

1. A program security charter will help you answer this question, and it’s a document that you’ll be able to constantly refer too, and refer everyone else too.
2. A security charter helps narrow the scope of your application security program, it helps go from the broad sense of the pillars into more specific information.
3. If the pillars are the foundation to the program, the charter is the framing, it’s important to note here that just as the foundation has to support the frame, the pillars have to support the charter.

Good references on how to write a project or team charter is pretty sparse, therefore it’s an exercise for the reader to determine exactly what their charter contains, however I believe that a good charter should address the following items:

1. Scope
   • Success Criteria
2. Deliverables
3. Dependent Groups & Liaisons
   • Internal Groups
   • External Groups
4. Participation
5. Decision Policy
6. About Charter

Scope

The scope of your team’s charter is going to determine the scope of the work that the team takes on or the program encapsulates. It is very important to ensure that the charter aligns with the pillars that are going to support the charter and the work, therefore if the pillars indicate that you’re going to focus on software security, it makes little sense to include server security and vendor third party applications in the scope of your charter, that’s a prime example of the charter violating the pillars supporting it and if you do so, then you’re only going to be in a world of hurt.

Part of scoping out the work, is determining under which criteria your program will be successful. When defining success, keeping a broad sense of success is important. To be too specific in what defines success, you set the program up to be potentially successful on 1 or two items, but then the executives are likely to consider the program a success and no longer see a need for it. Don’t worry just yet about how you’re going to measure success just ensure your success statement is successful.

An example of a good success statement would be:

To advance the security posture, both knowledge, and implementation of the application teams to produce measurably more secure software & thought process around designing secure software

An example of a bad success criteria would read:

To ensure that applications won’t be hacked or To harden the Software Development Life cycle by introducing security related activities into it

As you can see, the first statement is a broad statement that is ongoing, and yet it’s measurable because metrics can be designed to measure the success of the program under the criteria. Compared with the examples of not so good statements, both are very specific, the first sets an unrealistic measure of success, the second is so specific, that it should be an item that the program aims to achieve as part of success, but shouldn’t be the end and be all of the security program.

Deliverables

It’s important that your charter lay out the deliverables that the program is going to deliver on. Your application security program, and the team running it, isn’t going to be releasing production software, nor are they going to be innovating the next big product for the company so it’s important to effectively communicate what is expected from those participating in the security program. Ideas for what you might want to consider delivering as part of the security program are as follows:

1. Knowledge
2. Process Changes
3. Security Reviews
4. Architecture Review Analysis
5. Security Program (Documentation/planning)
6. Metrics
7. Guidance
8. Security Policies
9. Security Standards
10. Security Code POCs

This list is in no way exhaustive but is merely meant to get the discussion started on ways and the items that might be considered for deliverance under the security program.

Whatever is agreed to under your charter, it’s important that it have a measurable output, preferably through an artifact that can be directly pointed to a metric that can be verified further down the road if needs be. Notice how I did not mention secure code, hopefully the secure code will be the output & the result of the deliverables under the program and you should find a way to measure that.

Dependent Groups & Liaisons

Your charter should lay out the different groups that you’re going to interact with, both inside the program and outside the program. Engaging in this activity will also help you to more clearly define what the team executing your security program does and what other teams do. For example at Sun Life, I run the application security program, we still have to fall under the umbrella of Information Security, therefore when it comes to interacting with an outside group, we interact with Information Security, from an outside perspective because they’re responsible for writing the security standards, dealing with regulators, and incident response, all stuff I want absolutely no part in. The interaction makes InfoSec an outside group.

So too at Sun Life, our application teams fall within the program, because the program directly affects what they do, so it’s important to be able to know how you fit within the organization and what your roles and responsibilities are, a RACI Matrix can be useful here but should not be part of the overall charter.

So too, you don’t want to be overwhelmed or have everyone running to information security or you, all the time it’s important to know whom the contact points are in various groups to avoid stepping on someone’s toes and duplicating communication efforts.

Participation

Being able to clearly articulate who is participating in the program and what their individual roles & responsibilities are is important so that everyone within the program is on the same page. It’s also important to mention how many people are needed for the program to be successful, so that if someone leaves you’ve got an agreed upon document and can use this to acquire a back fill of a position or move someone else into that position.

This is also a good time in the charter to lay out, key time frames and commitments for individuals, are there going to be certain individuals participating all the time, part of the time, or on an as needed basis. This can be useful in resolving priorities and commitment issues later when those commitments and priorities arise over scheduling.

Don’t be shy to list everything that you need and how much of peoples time who are participating in the security program, it’s better to have someone dedicated 50% of the time in the charter and have them work 45% of the time then have them dedicated 25% of the time and spending 75% of their time working on items in your security program.

Decision Policy

This can be better thought of, as defining not only who has decision making power within the group, but also the method for making decisions, what decisions the program is responsible for.

Is there a chair or manager of the program, do they have the ultimate authority? Or is everyone equal and decisions are made by consensus, is there an escalation policy for when folks disagree?

Consensus decision making is good for open source organizations or volunteer organizations when participation is voluntary however, it’s not always good for private business. In private business sometimes when things go really wrong, unfortunately someone needs to be let go, therefore at the end of the day in private business it’s helpful to have a clear definition of accountability. I would advocate against consensus making decision policy in business.

Is the program capable of stopping or rejecting a software release due to insecure software? This section of the charter should clearly communicate the decisions the program is accountable for making or not making, who has the ultimate authority in making the final decision.

About Charter

This section is really about who are the founding members of the charter and program, how often it should be change, amended and is there a process for doing so? This section should really aim to define how changes are introduced, and when changes are introduced, is this charter good for 1 year 5 years, I would strongly recommend there be a time frame placed around when and where & how long the charter is in effect for. The charter might say it needs to be reviewed every 3 years, and every three years, there may or may not be any changes both are okay, it just allows for an opportunity to get folks together in a room to rethink everything that has been agreed too and any changes that may be needed.