The Federal Information Security Management Act of 2002 (FISMA) mandates very detailed security practices. The National Institute of Standards and Technology has an entire division focused on creating security guidance documents. As security becomes more of a focus the nomenclature of these documents seeps into your daily lingo. FIPS 199 and 200 describe the levels of risk and establish the security controls. You discuss creating risk management framework (800-37). The 800-53 list the security controls for high, moderate and low risk systems. The 800-53A explains how to perform audits of security controls.

This alphabet soup is intimidating and complex. This cuts into FISMA’s usability, but you must take the time to decipher the incredibly valuable information. So what happens? IT does what we normally do. We build the app to the best of our abilities then run over to the security desk and ask them to rubber stamp it so we can go to production. We “bolt security on” rather than “bake it in”.

Test, Test and TEST!!!!

Whether its security, usability or functionality its essential to test and find problems early when they are easier (cheaper!) to fix. But security is complex and scary. The FISMA controls effect development, operations (servers) and networking. People spend years becoming experts in each of these fields. Thus, it is incredibly unrealistic to expect a project manager or scrum master to catch every possible problem in each area.

Row in the Same Direction

This is where teamwork is essential to success. Players from each of these specialities must be involved. This is common knowledge to any project manager. This is what happens. The project manager request a senior staff member from each team to attend the kick-off meeting. They usually get whoever has time. Thus, the brainstorming session is attended by people with no interest in the outcome. Since they are all coming from such wildly different perspectives meeting usually ends with no direction or agreement.

Tweak Your Kung Fu

As you start to focus on feasible solutions you want feedback from security for potential pitfalls or questions so you can address them early on. The key is when you bring these other experts into your sessions. Bringing them in too late is offensive as it will make them feel like an afterthought. Bringing them in too early could stifle the free flow of ideas from the core, more engaged team.

I recommend having your first few “off the wall” brainstorming sessions with only the business experts and developers. They are suited to figuring out different ways to solve the problems. Use whiteboarding, brainwriting and other gamestorming techniques mentioned in previous blogs. The result of these sessions is a huge list of potential solution ideas. Cull them down to a more realistic list in your next session (using techniques such as affinity analysis). Once the potential solutions are down to around ten, then open the session to the experts from security, operations and networking. They are suited to revising an idea to fit within security, hosting or networking limitations

However, you must be very careful. You have to change your techniques a bit in these sessions. You don’t want to start over with the brainstorming sessions because you already stated focusing on feasible solutions from the business and developers’ perspective. Additionally, you must avoid the animosity that comes if the new people think they are there just to poke holes in the previous members work.

The key is to focus on scenario based exercises. Take each solution in turn and have the team visualize taking it all the way to production. Whiteboard the steps, then look at concerns from security, operations, networking, budget and training. These are high level steps like “build out virtual server instance”. Don’t let the team go into the minutiae here because you have many to cover. Set a time limit of about 15-20 minutes per solution. Keep it high level, keep it moving and keep it focused on successful outcomes. Get used to saying “That’s a valid concern, but how would you make it work?”

The most feasible solutions will quickly stand out after this session. You will likely have two or three solutions left. Spend the next session focusing on these candidates. Now you can dive in deeper. Spend about an hour on each solution. Don’t think participant will want to spend the time? At this point they are invested in the outcome and participation will not be an issue.

Each member will be more engaged during these sessions. They will feel included, engaged and vested in the solution. They are not coming in at the last second to look at an almost completed project. They helped form the solution. They took an active part early on so the solution will be more robust.

Try it in your organization. Experiment and mix and match. Ask for feedback from participants after each session. This will help you tweak the process. Don’t be afraid to experiment! If you take good notes on what did and did not work, you will find the right techniques for the culture and personalities in your organization.

It has been a great experience being part of the first ever Featured Blogger program! Thanks for reading!

• NOTE: All views and opinions are those of the author only and not official statements or endorsements of any public or private sector employer, organization or related entity.