Security Ripcord

Work has been quite an experience over the last couple of months. I have spent my time in the usual security professional mode – Firefighter. It is especially aggravating when much of that firefighting is documentation for certification and accreditation of a system (that could be quickly improved with the same level of effort) or collecting information through what could be considered broken processes. Security Blog readers hear about both of those concerns all of the time as they peruse the Security Blogscape. Security professionals wishing that they could make a difference within their organization. Wishing that the managers of the system and network administrators would just listen and implement. Hoping that the executive management will empower the security professionals within their organization by conveying to the rest of the company the importance of secure operations. Let’s face though, when we start talking about security within our different organizations the majority of what we want is for our organizations to follow good business practices. Companies who have a firm grasp on how their technology operates and have a process for change through open communications are much more secure that the companies that buy security products to act as stop gaps and try to prove or give the illusion of compliance.

The next generation of security professionals need to recognize this fact. Certainly we train them to know that their companies should be following industry standards like ISO 27001:2005 as I have already pointed out. But have we really started providing them with the abilities to integrate this into ITIL or CMMI. No, that is because for a business to achieve these standard they need to have business professionals to guide them through the process. Unfortunately, these business professionals have not been trained on how the security frameworks will fit into the organization and their compliance efforts. So, there is a gap. And when there is a gap that people don’t understand they tend to do one of two things:

• Ignore it.
• Throw money at it until they wish they had gone with the other method.

We’ll let me let all of you in on a little secret. It is something that you can take back to your organization and begin to implement immediately and it will not affect anybody outside of the security group, at first. Are you ready???? You might just hate this answer, so stop reading if you cannot handle it. Okay, I want you to “Document Your Processes!” *Gasps are heard around the world* Yes, documentation will get you over the hump. I’m not talking long, drawn out documentation that makes you stop everything that you are doing. No, I am talking about quickly documenting the steps you take to address any issue you devote time to repeatedly. I am also talking about creating process flow diagrams that show where and how tasks touch other departments within your organization. Don’t spend a lot of time on it at first. Just get it written down and saved into a location that all of your team members can access it. Then print them out and put them in a binder that will become your Standard Operating Procedures (dang, how did SOP slip in there?). As this binder starts to fill up, make copies and deliver a a copy to your boss and the other managers of the departments you deal with on a regular basis.

Now the ITIL and CMMI experts are ready to jump in here and tell us, “This is not enough to be compliant.” They would be correct. But each of them will have to admit that it is one way to start down the path. It is a necessary step that they will be looking for as they go down their checklists. See, a few of the things that they want to see from you and your department are:

• Does your department have documented processes and procedures?
• Does your department control their efforts through some type of program or project management method?
• Does your department have methods to analyze and improve the processes and procedures?
• Does your department make these process and procedures available to other departments within the organization?

By documenting how you approach each one of your department’s responsibilities you will start down a path that can be successfully integrated into the organization’s business processes. Managers will be able to start looking at your productivity and perform metrics on your duties which will help them determine many things, such as your value to the whole organization or whether your department is short handed. And what does it do for your department as a whole? You become more effective and efficient because you start doing things the same way every time (until it does not make sense to). You have opened communications to the rest of the organization and provided them with a method to take your example and some of your ideas and turn them into their own ideas (oh, the power of suggestion). All of this documentation you will help you and other members of your department quickly determine where your processes need improvement. Process documentation is an excellent tool when it comes time to point out issues to the members of your department. It drives straight to the heart of the problem in a manner that is easy for them to understand and provides them with the opportunity to make visible and fulfilling improvements.

Is all of this enough to “fill the gap” that I spoke of earlier? Of course not. It is just a start. One of the things that I am starting to consider are classes and certifications in program/process management. For this I have been pointed to the Program Management Institute by several security professionals and bloggers. I really don’t think it is going to hurt any security professional if they add PgMP, PMP, or CAPM to their alphabet soup. In fact, as individuals begin to progress through their careers these or similar education may become necessary. Many of our technical Brethern (who are still reading) are shifting uncomfortably in their seats because dreams of management duties are starting to fill their heads. Those, at least, that don’t come from a structured software or hardware development background. And they shouldn’t. Because these are the skill sets that are also necessary for technical engineers to improve how they do their business as much as it is a means for the managers to improve the department or organization.

Open communications is one of the things that we promote within our organizations. If your organization is “open communications challenged” then you must first start looking at yourself before you start pointing fingers or stomping feet. You must set the example. Live the lifestyle you preach. Hopefully it will make a difference. If it does not, well, then at least you have improved yourself and your department. The people around you will be more prepared for the next thing that comes along.

Go forth and do good things,

Don C. Weber

This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported.

You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.