4 Ways to Improve Information Security Engagement

A few weeks ago, in one of the groups I am connected to, a discussion was started regarding how to improve the engagement of the Information Security area within the organization. In my experience as a security consultant, it is not uncommon to find the Information Security group somewhat on the “outside” of normal operations. A few symptoms of this situation are things like: the security group finds out about a deployment of a new system/service at about the time they want to start testing; security members are not part of the regular change management meetings; project management processes in the organization do not specifically require information security participation or signoff; or, a new system is discovered accidentally by the security group during the course of their normal activities (or maybe a help desk call).

This is not an ideal situation in that the company’s solutions may be deployed in a way that opens the organization up to more risk than they realize. It also makes it difficult for the security professionals to feel like they are contributing to the success of the organization and can contribute to low employee morale. I mean, who wants to be a part of a group that nobody wants to work with?

So, how can this condition be alleviated?

The following are a few things I have seen help to bring about positive change in the connection of security groups with the rest of IT.

Probe for Requirements

Something interesting I’ve noticed over the span of my career has been the change in how a non-technical user approaches the addition of something new into the environment. Early in my career (I’m getting old, so this means a long time ago) users would come to the table with an idea of what it is they wanted to accomplish. Maybe it was a new function for an existing program, an enhancement to an already present operation or it could be a brand-new idea to help move the organization forward. Regardless, they would come and describe what the idea was in enough detail to help those listening understand the end result. Those listening might then ask a few more questions as they think in terms of how they might solution the idea. Basically – this is requirements gathering at its simplest. This approach was required because the end user was not tech savvy enough to be able to “solution” on their own.

Fast forward to today where we have, on the edge of our credit-cards, functional solutions that are available directly to the consumer. With the availability of higher bandwidth, more mobile applications and elastic-computing which has revolutionized “the cloud”; the end user has gotten out of the habit of needing to describe what they are looking to do and just find a solution that they thinks meets their needs and request that the organization start using it (I realize that I might be stretching the truth a little; most end users will not ASK if they can use it - they will just START using it).

This makes it difficult for the security practitioner who may just say “No!” (see the next section) or scramble to figure out a way to secure this solution that was never meant to be deployed in a more traditional security environment. What’s missing here is the discussion about the requirements of the user.

It’s at this point where the security practitioner needs to ask a few questions to (A) create engagement with the user; (B) gather information about the solution in question; and, (C) consider what existing solutions that are in place that may meet the requirements. Ask the following:

1. “What, specifically, are you trying to accomplish with this new solution?” – this provides some insight into what exactly they are looking to get to with this new suggestion. Make them be SPECIFIC.
2. “What is it about the solution that you really like?” – this will help you understand the driver or the key features of the solution so that you can compare it to what you may already offer.
3. (If you have an existing solution) “What is it about our current offering that is not appealing?”- I don’t think we ask this question enough in the security space. Understanding what users don’t like about a solution may allow security practitioners to make simple adjustments that will improve the overall experience.
4. “How does this new solution fit (or integrate) into the existing portfolio of solutions that we already have?” – Most users will not have thought about this at all, rather they were just looking to solve a point-in-time issue that they are dealing with; however, this is critical to understanding if a solution is a ‘fit’ for the organization. It also helps identify to the user that solution implementation may be more complicated than they first realized.
5. “Is there anything in our current offering that may do what you are looking for?” – There is a chance that there is something, but for some reason the user does not want to use it; or you might be able to make a recommendation as to something that could meet the need. This may lead you back to question #3 and provide some useful insight into what the user is specifically thinking about the existing solution.

By asking these questions, you are improving the engagement with end user making them feel like they have been heard. Make sure that you don’t just leave it at these questions – keep track of the request and be sure to follow up with either other potential options or new implementations which can address their issue. You can be assured that they will appreciate being listened to.

Stop saying “No”

Security groups that find themselves on the “outside” of the normal system development process still say “NO” a lot. This stems from the fact that because the security group is not engaged in new solution development, they are often brought in as close to the end as possible because the rest of the organization is struggling to work with them. At this point timelines are short, the solution is most of the way completed and they are looking to get the blessing of the security group before actually moving into production. In the worst of cases, the security group is approached after the solution is already up and running in some form of production manner.

It’s at this point that the Security group says “No” and tries to stop the solution deployment so that they can add-in the security stuff that they need to make the deployment secure. This can go usually one of two ways: (1) They delay the project, attempt to add the security measures (which are always more expensive and time consuming after the fact) and then finally deploy with only half of what they would have wanted to do; or, (2) the project is already behind schedule and those in IT Leadership who are tasked with delivering this to the business, decide to proceed without the security controls.

Neither of these paths leads to anything good for the organization. As a matter of fact, the whole process is cyclical and self-defeating. The security group says NO and the rest of the organization takes another step back from them as they provision solutions. Solution providers, now further removed from including security, charge ahead with the next solution without security because the last one managed to make it through without their blessing anyway. And on, and on, and on it goes creating a great divide within IT and having organizations deploy solutions that are potentially putting company resources at even greater risk than they had realized.

There is a way to break this cycle, but it will take a concerted effort on both sides of this issue. Start with these items:

1. IT Security: Don’t say NO – What you need to say instead is, something to the effect of: “Yes, we can help, and here is what we can do to secure this solution…”. This is hard to do given that you had most likely been brought in at the last minute and you have a number of other things to do already to keep the security lights on. But – if you want things to change – you are going to need to say more yeses and then pull a rabbit out of a hat to make it work. Someone has to break the vicious cycle – it might as well be you.
2. IT Projects: Include IT Security in the project from the beginning - so that they can bring up the stuff that will need to be included in this solution to make is secure. This is hard to do when all that the security group says is “No”, so you may have to take the first step and invite them early into the process. Tell them that you want them to be able to say “Yes”, and that’s why you are bringing them in early. And, if the last time that you approached them at the last minute and they said “Yes” (as noted in #1 above), then for sure make sure to invite them early next time as a form of reward.

The goal of the information security area is to aid the IT group in producing solutions with an appropriate level of security. Since IT’s role is to provide technical assistance to whatever the business functions are, all of IT needs to ensure that it’s goal is to work towards solution development and maintenance for the business function of the company. You are all on the same team – so function in your role in a way that moves the ball forward for the whole organization. And that starts by saying “Yes”.

Don’t wait – build a security services model

I have often wondered if most of the time that the information security group is not included in the new projects because it seems as though there is no consistency to the security treatments that are used for the organizations solutions. One in particular that gets a lot of attention is the use of a second factor of authentication. I have seen numerous instances where project participants try to compare their new solution to an existing one that does not have a second factor of authentication requirement; and the explanation why is not always very clear. In general, the application of security solutions comes across as hocus-pocus, black-magic or voodoo like to those who are not part of everyday security operations.

A few years ago, I recognized this as an issue and created a model to help make it a little clearer why certain security treatments were used. I called the framework: Risk-based Information Security Approach, or RISA for short. In order for RISA to function you need two things:

1. An Information Security Data Classification – this is usually separate from your corporate data classifications because it will lend itself only to the information security implications of the data it is applied to.
2. A Security Treatment Matrix – This matrix utilizes the classification of data just previously noted and intertwines this with what is called a “layer” and an “aspect” which results in a pre-defined security treatment.

The layers described above are 8 tiers of the IT structure that all organizations will encounter. They include the following:

• Data
• Application
• O/S
• Hardware
• Logical
• Physical
• Personnel
• Governance, Risk & Compliance

The aspects are as follows:

• Predictive
• Preventative
• Detective
• Responsive

As a simple example, let’s assume I have a 5 level Security Data Classification (SDC) mechanism, with 1 being the least sensitive and 5 being the most sensitive. Starting with the Operating System layer, I can look at each of the Aspects and SDC’s and identify what security measure needs to be taken. The chart below shows a portion of what the matrix looks like:

The point of this is to take the guess work out of what security treatments are required as each new solution is moved through inception to production. It even would allow these items to be available to the project team before they ever start a project. Granted, the setup of the RISA Matrices would take some time, but it provides each organization that utilizes it, its own way of identifying how much security is enough for them and what they will apply at each of the layers.

The full RISA Whitepaper can be found here: RISA Whitepaper

Work broadly within the organization

Many times, when I work with Info-sec groups, they operate a little like they are on an island. Granted, this may be because of previous things written in this post; however, it’s hard to be engaged with the rest of the organization when the only person that you talk to is ‘Wilson’ (reference to the volleyball from the movie Castaway).

To increase the “surface area” of the IT Security group, there are a couple of other sections where you can find some commonality. If your organization is large enough to have them, try reaching out to the following groups:

• Internal Audit – although it may not seem like it at first, there is a fair amount of similarity in function between Info-sec and IA. IA’s role is to ensure that the internal controls, governance and risk management components of the organization are effective; and they do so in an independent manner (like being on a neighboring island to the info-sec group). In most cases, they are also directly connected to the Board of Directors through some form of risk or audit committee. Info-sec is responsible to ensure that security operational risk is kept to a level acceptable to the organization. By regularly meeting with and sharing information with IA, you can be sure that important risk items are at least noted and have the potential to reach the board. Since IA is normally covered by some form of independence clause, your interactions will need to be kept at a mostly one way information sharing, where you provide them with updates on risk related items. Depending on their charter, they may be allowed to ‘consult’, which is ideal for info-sec in that they can provide advice on things to focus on. Your information sharing may also make its way directly to the board and help shape upcoming audit plans. Don’t underestimate how powerful it can be to regularly communicate with IA.
• Enterprise Risk – In a similar vein to IA, Enterprise Risk Management (ERM) also focuses on the wide view of risk for the organization, however they do so in a planning/strategic way that can contribute to the forward operating plans of the enterprise where IA simply validates and reports on the progress of the risk items they review. Similarly, to IA, ERM has a very wide birth when it comes to the risk measures it looks to implement within an organization. IT, and subsequently IT Security all falls into an operational risk category in ERM’s taxonomy. By working with ERM, IT Security can ensure that the communication between the two groups is at least using the same language. I have found that most ERM groups welcome an IT Security group that has spent the time to clearly articulate its control matrix (see above: “Don’t wait – build a security services model”). Once something like this has been shared with ERM, it is possible to garner some higher-level support for the initiatives that may be lacking in the model. Remember that ERM is also usually connected to the board. [NOTE: Some schools of thought indicated that IT Security should report into ERM instead of IT]
• Other IT Groups – It should go without saying that other IT groups should also be on your list of areas to connect with on a regular basis. This keeps the communications lines open and fluid and allows the IT Security area to garner information about things that are going on in day to day activities within the environment. The Server, Network and App development teams should be high on your list.

To be effective, the Information Security group needs to be engaged in several aspects within the organization. As noted above, there are at least 4 ways to improve this engagement as follows:

• Probe for Requirements – This not only gets the conversation going with end users but also provides a means for them to understand the process Info-sec goes through when implementation solutions that support the goals of the organization.
• Stop Saying “No” – Info-sec is a support to IT which is a support to the business areas of the enterprise. Continually saying “No” simply further isolates the Info-sec group and lessens the likelihood that security will be engaged going forward.
• Build a Security Services Model – This not only takes the pressure off having to come up with your security treatments on the fly, but also gives you the opportunity to publish these services so that other know in advance what kinds of things to expect when new IT project are commenced.
• Work Broadly – Having multiple parts of the organization to consult with means that info-sec has a better opportunity to understand what is coming down the project pipe and to convey info-sec challenges to various parts of the organization.