In many of the places that I have worked, both as a consultant and as a part of a product delivery team, it is usually a case of keeping the Enterprise Information Security team (EIS) at arm’s length. Truth be told, many teams hold to the old adage that the less EIS get involved, the better. Even more so with agile delivery, as the focus towards shorter, more targeted delivery means that EIS is a thorn in product delivery’s side. And though this article leans towards agile delivery, the points made are equally applicable to any waterfall delivery.
Using agile thinking, I have learned that bringing EIS into the team is, by far, the most effective and efficient way of delivering a better, more secure product.
I currently use a five-step process for establishing our ways of working between EIS and delivery teams:
- Security Principles: It might be regarded as basic but I am continually amazed at the number of times I ask for the enterprise security principles and I am given answers from “No”, to “Sort of” and “we are currently refining”. Before any relationship can begin, these principles need to be put down on paper and baselined.
- Checklist (Impact Analysis): Normally agreed between EIS, the Architecture team and the Product Owner. (if capable) This list will form the backbone of all conversations between the parties
- Checkpoints. It’s no use just talking at the beginning and then again at the end. We need to look at the features/product/epics, as they go through their journey and to keep bouncing the EIS guys to make sure that they agree.
- Adding to the backlog: Simply put, items raised will be put in the delivery backlog, estimated and fit into an iteration.
- Sign-off: From a simple thumbs up to a signature in blood, it’s your call. The bottom line is that all agree.
If you wish, you can stop reading as I have given a very basic, high-level view but below, I have gone into more detail, breaking down each of the five steps into a suggested next level of detail. Enjoy!
Principles
Any information security policy will focus on the three core principles of confidentiality, integrity and availability and from agile, I add one more, continuous improvement. The below are a good starter for 10:
- A centralised security policy
- A robust and standard security model and associated controls (agnostic to hosting env), which is constantly reviewed and updated
- Secure Information – Make sure all data is protected
- Access Control
- Assist in trusted and efficient access for administrators and users. Secure but easy to gain access for authorised users
- A robust AAA plan (Authentication, Authorization and Accounting)
- Centralised Access Control System
5. Other areas to consider
- Architecture that supports the business benefits of cloud computing
- Defence in depth
- Security Event Management
- Adherence to any company standards
- etc
Owner: EIS
Checklist
The checklist is crucial in the relationship between all parties. It provides an outline of the circumstances when EIS will need to be involved in any change. The list needs to be comprehensive enough to include all security related flags and needs to be understood and agreed by all parties. If implemented correctly, it reduces the involvement and effort from EIS, with the team only involved when needed. It also gives confidence to the delivery team that they have taken all the necessary security steps as and when needed. Here are a few guidelines
Does the change impact/alter/add to:
- Security Principles
- Data
- Authentication/Authorisation
- Monitoring/Logging
- Design & Functionality
Owner: EIS / Architecture Team
Checkpoints
While the checklist defines if EIS need to be brought on-board, the checkpoint outlines a simple process framework for when collaboration is needed. I use the following steps:
Checkpoint 1: During the ideation phase, where the work is predominantly around backlog refinement, with the PO as the gatekeeper. As we beef out the ideas, the PO will need to bring in security to run the high-level concepts by them for their views.
Checkpoint 2: When we have a good view of what we are going to start to work on, but before we have approved for delivery. At this point, it is usually the Architecture guys who take the lead with EIS. Note: We could put an action item in our Definition of Ready
Checkpoint 3: This is the tricky part when using frameworks like Scrum. The delivery team, architects and EIS need to stay in contact on an iteration by iteration basis, to make sure that EIS are up to date on new functionality. Leaning on the checklist and agreements in places from checkpoint two, delivery need to make sure that they communicate the latest security-related specifics to EIS while EIS need to understand and adapt to the underlying agile approach to change.
Checkpoint 4: Retrospective. Bring security into this forum. They should be looking at CI as well as the rest of the teams. The Security Policy and the Security model should be shaped by the outcome of the retrospective
In my experience working in digital delivery and using the checklists and checkpoints principles, I have found that EIS do not become embedded in every single activity. I am surprised, when the process is in place, how little we need their involvement. A solid checklist, agreed and continuously reviewed by all parties, gives the agile team the trust they need to collaborate early on and only when items are EIS related without the need for audits and security reviews. I am sure that others will have a very different experience but it all depends on the work you are involved with.
Owner: Agile Team
Adding to the backlog
If EIS and product management and delivery are working together through our product development process, then, EIS will be bringing items to the table. These new requirements will naturally fall into our backlog along with all other items, adding both user stories and acceptance criteria. In fact, this very process will begin to intertwine the work that EIS and Delivery do, and lead to a more collaborative approach between the teams, bringing security into our delivery.
As a final note under this heading, I point out that specific security processes like threat modelling and other practices are managed by the EIS team and need to happen in parallel to the process. In fact, items like technical debt, enablers etc are an article in themselves. But in the end, the items raised will be put in the backlog, estimated and fit into an iteration, with all the other stories.
Owner: Product Owner
Signoff
I won’t say much on this topic. I will defer to the Agile Values “Working software over comprehensive documentation”. Whatever that means to you and your enterprise
Owner: EIS
Security needs to have an important place within agile software delivery and collaboration between security and delivery needs to be ingrained into the DNA of product delivery. Similar to any other part of our enterprise, by bringing them all together, working as one team and continuously improving is the best way to deliver value.
In the words of Captain Jean-Luc Picard, “make it so!”
PS: in this article, I have avoided any focus on DevOps. Needless to say, the above process will need to be tweaked as you proceed on your DevOps maturity journey!
