How many times have you been at a project meeting, maybe a status update meeting, and heard a voice that isn’t familiar to you speaking up for the first time.
“Ah... we need to put 5 days in the project to do our VA”
A meeting room full of people turns their heads and looks at the face of the unfamiliar voice. “You need what?” the Project Manager barks.
“We need 5 days, you know, between the build and go-live for the VA.”
A Sr. Business Analyst with many years of experience pipes up, “That just won’t work. We need that time for the QA and sign-off.”
The PM, who has worked with the Sr. BA on other projects, shakes his head in agreement, “We just don’t have time for a VA, what ever that is, now let’s move on to the next item.”
That unfamiliar voice at the table was an IT Security Analyst, facing a common challenge in the modern day business, getting the project implemented, while ensuring the right security controls are in place.
Where a Business Analyst typically looks at requirements for a project to meet the objectives of the business, or a Systems Analyst looks at the needs of the technology to enable the business to meet the objective, a Security Analyst has too look at the dream. The “dream” encompasses “we would like to make money” to “we are opening up this firewall port” and everything in-between.
The overall goal of the Security Analyst is finding and mitigating risk to the business, the businesses assets, and the technology infrastructure both current and future. We need to take in an insane amount of factors in about a project and calculate threats, vulnerabilities, and the likelihood of exploitation of these. Mix it in with a little gut feelings based on experience, and inform the business that what they want to do may introduce or magnify risk to their organization.
A Security Analyst needs to have a good dose of logic and reason in them with a willingness to learn.
One typically does not start their career as a Security Analyst; it just is not possible to fill the role without a broad level of experience. Often a Security Analyst has gone through many non-security roles before deciding to move into a dedicated security position. It is typical for someone to start out in a help desk, move to server administration, transitioning to a network team, and then maybe to security administration, before moving into the security analyst role.
No matter which path is taken, a successful Security Analyst will have a strong technical background with a deep understanding of how everything works; you just can’t get by in this job without having done the job of everyone else around you first. This is an imperative point because every piece of technology the business implements impacts the infamous security triad, which is confidentiality, integrity, and availability. If you don’t understand the inner workings of an e-mail server, all the different configuration settings, networking requirements, access controls, and so on, then you may miss a critical vulnerability when doing a risk assessment.
What differentiates a Security Analyst from and engineer or administrator is the ability to understand the security relationships at the people, process, and technology levels, and roll up findings or concerns identified at each level to a risk the business can understand and act upon. The Security Analyst role interfaces with the business in much the same way a Business Analyst does. We walk the fine line between the technology teams and business teams acting as an interpreter to each group.
For example, when the business says “We need to prevent Larry’s team from accessing the financial reports” the security analyst tells the technology group responsible for network access to “Deny read and write access to the Financial share on the NAS for the members of the Customer Service user group”.
At the same time, if the network service group says “We need the terminate the Finance group VLAN on the 2nd tier DMZ to prevent Larry’s team from accessing the NAS share” the security analyst will tell Larry “Once the network guys flip the switch your team will no longer have access the Finance share on the network.”
The responsibilities of the job are seemingly endless, but some typical tasks might be:
Now many of the tasks mentioned above could be foreign to you, however, the point is that a Security Analyst will be doing a very diverse group of tasks, and many at the same time, which is what makes it an interesting job. On the flipside, one of the challenges of the job comes from the events detailed at the beginning of this story, getting input and time into the business lifecycle.
Unfortunately, information security is a cost center; money goes out and never really comes in, although there is a lot of ROI when a security program is implemented correctly.
There are several points in the business lifecycle of a solution where the security analyst needs to get there hands on, offer opinion, and enforce policy or standards. When the project manager has allocated two-weeks for a particular phase of a project and security finds something that could delay that two-week window, we often get the short end of the stick.
That is why security analysts, business analysts, systems analysts, and project managers, all have to work together in a collaborative manner and understand each other roles and responsibilities.
In my next column I will dive into this point a little more and talk about how our worlds intersect, as well as show where you can help someone like me in maintaining security throughout the lifecycle.
Author: Stewart Allen is a certified Information Security Consultant based out of Toronto, Ontario, Canada. If you would like to comment on this article or make contact he can be contacted on LinkedIn at http://www.linkedin.com/in/stewztheone