Showing posts with label management. Show all posts
Showing posts with label management. Show all posts

Saturday, April 11, 2015

Think twice before pursuing a career in information security...

...not because its a bad idea. But a little planning and introspection will go a long way towards charting a course that you'll be happy with.

Over the past few years I’ve had the opportunity to do a fair amount of recruiting and hiring, with a focus on engagement and retention over the long term. One of the great things about the job is to see people find the right role fit and really take off.

Broadly speaking, Information Security is a great field to be in. By nature of the work, it offers many of the things that drive employee engagement: job challenge, variety, and opportunities for advancement. But some of these roles can also be high pressure and require long hours. Stakeholders can be difficult at times, and by definition there are limited opportunities for visibility and recognition for the highly sensitive roles. Stress and burnout are common risks.

Recognizing and addressing these issues is a key role of management. But staff, especially new staff, should be aware of these potential pitfalls when charting their career in information security. 

If you decide you want to work in Information Security, check out these guides as they point you toward the technical skills you will need. But also be intentional about where and how you want to work. It will make all the difference in the world.

If you have a role that leverages your strengths, you’ll feel energized by the challenge, even if its high pressure and high stress. And likewise, any role that consistently requires traits and skills where you don’t perform well will be draining and can potentially burn you out.

Nearly identical roles in two different organizations may need very different things from the person they hire. It depends on a number of factors including the maturity of the organization, the culture of the team, the industry they support, and the threat environment they face.

The best candidate for a specific job is the person whose strengths and interests align with the needs of that function, and who’s attitudes, habits, knowledge and skills qualify them for the role.

Below is a high level overview of the kinds of roles that will exist in an effective security organization. It may not be representative of a specific company, or include everything that a security program does. But these elements will be present, and the level of emphasis for each category will depend on the needs of the organization:

Business Information Security Officer (BISO) - This role (not necessarily a title) is a stakeholder-facing representative of the security organization. They ensure that the capabilities of the security organization are integrated within the business. It can also include assessments of internal security projects and external vendors. Information classification, risk assessments, and prioritization of security technology deployments via an information security roadmap can also be included. This is the “sales force” of information security. BISOs learn about business goals, match capabilities to business needs, translate security requirements into business terms, win buy-in, and keep the program moving. Typically this role is more interpersonal than technical.

Security Operations - These are the request-driven functions that involve repeatable processes such as Identity and Access Management, break/fix support and exception management for user-facing security tools such as endpoint protection, device control, or data loss prevention. Firewall/VPN management can also be a Security Operations function. Some requests are simple, others can be complex. The work is process driven, and there’s consistent customer interaction. Its a mix of interpersonal and technical, but once you master the learning curve, the work can become routine. From a delivery perspective, the work is measurable and this makes it a good area for driving process improvement. Many of these responsibilities are also prone to offshoring, which means that retained roles within the organization are often specialized or involve inspection and oversight of offshore resources. Organizations that like to create a ‘pipeline’ of talent can bring in candidates into Security Operations due to the (relatively) short learning curve, and then advance the high aptitude team members that excel.

Governance, Risk and Compliance - GRC analysts help define the policies and standards that ensure internal compliance and external regulatory requirements are met. They assess the current control environment and identify missing capabilities, evaluating the risk to the organization posed by those gaps, enabling senior business leadership to decide which risks to accept and which need to be addressed. These roles are often less technical, although a background in IT Operations is very helpful. 

Cyber defense - On the surface, these are considered the “fun” roles of infosec, such as threat management, vulnerability management, penetration testing, forensic investigations and incident response. All are technical, and sometimes high stress. Long hours are common. Depending on how the roles are structured, processes can also become very routine. Except at the management level, these functions can have less direct end-user contact than BISO or GRC. Skills aside, not everyone has the temperament to really dig in on these kinds of roles and thrive over the long haul. Some organizations mix GRC, Cyber and BISO work within the same role so that the work isn't repetitive. But generally speaking, the larger the organization, the more specialized the responsibility.

Security Engineering and Architecture - in a “plan, build, run” IT model, this function does the plan and build. It can also include application security, data sanitization and other highly technical functions. This team evaluates the limitations of existing capabilities and prepares the case for adding new functionality. Once chosen, they properly size the solution for the environment, and start the process of integrating these capabilities. They also interface with peers across the rest of IT, vendors and professional services organizations to integrate these solutions. Project management discipline is important here, along with defining and also adhering to technical standards. As with cyber defense, these roles are highly technical. Depending on how the work is structured, it can have less contact with business stakeholders than most of the other roles.

Is this everything a security organization does? No - there's a lot more that could be said about Privacy, Disaster Recovery, or other domains of information security. But as a general rule, at minimum, effective organizations contain these functions. 

In Managing Oneself, Peter Drucker opens with these 4 questions:

  • What are my strengths?
  • How do I perform?
  • Where do I belong?
  • What is my contribution?

The more you know about what drives and enables you to make the biggest contribution to an organization, the better prepared you will be to target the right roles for you. 

Two caveats:
  • Sometimes you'll have strengths that aren't needed at the entry level, but they become critical at higher levels of the organization. Be patient, work hard and grow. In basketball they say “let the game come to you.” Its true in InfoSec too. In a healthy organization, talent is a magnet for new work.
  • What if you're not sure which functional area is best for you? You may want to work in a smaller organization, or one that defines security boundaries per region. This gives you the best opportunity to sample multiple responsibilities. Another option is to network within the organization, and volunteer for cross-team projects. Explore within the organization, but don’t job-hop unless you have a good rationale for it.
With this in mind, do all the homework in advance that you can to chart the course that’s best for you. Use LinkedIn, job postings and other details to map out organizations that you're interested in. There you’ll find your best chance for success.


Best of luck!

Tuesday, January 27, 2009

Making the most of forensic downtime

As a computer forensic investigator, at times the caseload can become a bit overwhelming. Sometimes the requests come pouring in; other times the queue will be empty. Looking back through several months of work, you can put together a reasonable estimate of the average arrival rate and average completion rate for forensic investigation requests. Armed with these two pieces of data and some equations from queuing theory, you’ll be able to estimate the amount of cumulative non-investigation time that will likely be available for other tasks over the course of a year.

Naturally much of that down time should be spent “sharpening the saw;” maintaining tools and scripts, etc. But as discussed in the last post, it may also be helpful to leverage those forensic tools and skills to measure risks in the end user environment. Taken periodically, these measurements support the execution of a security strategy by providing the evidence needed to drive changes that will ultimately reduce the frequency and impact of incidents that do occur.

Queuing theory can become complex in a hurry, but there are a few formulas that are easy to use and very helpful if you make a few reasonable simplifying assumptions. For the long version, check out Contemporary Management Science by Anderson, Sweeney and Williams. Or an online excerpt of the relevant chapter is available here.

If you know the average arrival rate of requests, and have a good feel for how long it takes to complete the typical investigation, you can calculate the following:

1. Probability of an empty queue with no requests in process:
1 – (arrival rate / service rate)
2. Average number of pending requests:
((arrival rate) ^ 2) / (service rate * (service rate – arrival rate))
3. Average number of investigations in the systems:
Average number of pending requests + (arrival rate / service rate)
4. Average time a request has to wait before the investigation starts:
Average number of pending requests / arrival rate
5. Average resolution time; from initial request to completed resolution:
Request wait time + (1 / service rate)
6. Probability that a new request has to wait for service:
Arrival rate / service rate
7. The probability of N number of investigations and requests that are in the system at a given point in time:
(arrival rate / service rate)^N * probability of an empty queue

These equations provide a good approximation if the following assumptions hold true:
1. For a given time period, you’re almost always going to get between zero and 2 requests (i.e. 95% likely) and only rarely do you get a bunch of requests (5% chance of 3 or more requests arriving at once).
2. Few service requests will take significantly than the average service time to complete.
3. You’ve got one investigator servicing requests – a “single service channel.”

So, as an example, suppose the average request arrival rate is about 3 cases per month, and an investigator can complete about 4 cases each month. Calculate expected downtime using this proces:

First, convert the monthly numbers to a weekly rate, 3 arrivals per month is a 0.75 weekly arrival rate, and 4 completions per month is a 1.0 service rate. Then, plug and go:

The probability of zero requests in queue is:

1 – (.75 / 1) = 0.25

A 25% chance of having a week with no requests in progress.

So in this “best case” scenario, roughly 25% of an annual 2000 hours worked won’t be directly allocated to investigating live cases; 500 hours. In reality, this estimate is almost certainly too low for a couple of reasons. First, management isn’t likely to over-staff a forensic role; demand will rise to fill that capacity, and inevitably many long-running difficult cases will come up that fall outside the average completion rate by a big margin. And investigators will need to factor in time for script development, system administration, and other tasks.

Assuming that a residual 200 hours (10%) of time remains available throughout the course of the year, this can provide the perfect opportunity to quantify policy compliance against specific goals.

So how much can you do with 200 hours? Turns out, quite a bit.

Sunday, October 26, 2008

Can you afford bad security?

Within the current economic turmoil and uncertainty its becoming clear that the global economy is slowing, pressuring organizations of all sizes to compete more intensely for revenue while taking an even harder look at reigning in costs. These concerns cascade through the overall project portfolio to IT and security in the form of two very basic questions: What do we need? What can we afford?

In a company fighting for its survival, talking to management about improvements in information security may seem as relevant as changing the locks on a burning building. Naturally, fire is an immediate threat to an asset and its contents, but over a longer time horizon so is the risk of theft … or foreclosure.

Bottom line, some organizations can afford bad security. Others can’t. In some situations, immediate survival concerns will temporarily trump long term protection goals. But as the market meltdown in the United States in 2008 is showing us, it is just as plausible to see that relaxing key control requirements for short term profitability puts entire companies, and even markets, at risk.

The only way to get this right is to view security in light of the survival needs of the firm, and measure it to the same standard of every other investment. In the past, information security hasn’t been held to this standard, mostly due to measurement challenges. Hopefully, for the good of the profession as well as the entities we protect, those days are over and we can take up the challenge of proving our value more accurately and more persuasively than we have in the past.

“What the CEO wants you to know”
In 2001 Ram Charan wrote a gem of a book called “What the CEO Wants You to Know,” distilling business acumen into the effective management of five core measures of business health: cash, margin, velocity, growth and customers. Charan: “Cash generation is the difference between all the cash that flows into the business and all the cash that flows out of the business in a given time period …it is a company’s oxygen supply” pp.30-31

Margin is the difference between the price and cost of goods sold, while velocity is the rate at which those goods are sold. Growth includes expansion (more sales) and extension (new markets) while the Customers category represents how well the organization responds and aligns with market demands.

Naturally, some of these needs can become tactical and immediate while others are more strategic in nature. But all must be functioning effectively for a company to succeed, and any threat to these measures ultimately threatens the health of the company.

“What the CISO wants you to know”
If the five factors above represent the keys to a successful business, then good security is important to a company only to the extent that it affects those factors. If there’s no impact on customers, growth, etc. then there’s no value to security. Or, as your CFO probably read in school:

“A potential project creates value for the firm’s shareholders if and only if the net present value of the incremental cash flows from the project is positive.” [Brigham and Ehrhardt, Financial Management: Theory and Practice, 11th Edition, p.389]

Security issues expressed in terms of cash, margin, velocity, growth and customers, and measured in terms of net impact to the company have the best chance of resonating with decision makers.

Gordon and Loeb propose a three dimensional Cybersecurity cost grid as a tool for building that business case. The authors suggest failures of confidentiality, integrity and availability are to be analyzed in terms of direct and indirect costs, as well as explicit and implicit costs.

For me, the distinction between indirect and implicit didn’t seem as compelling as the difference between a net positive or negative effect on security, so I started segmenting the effect of security across Charan’s five categories this way:



Of course, measuring it is the real trick. But there are quite a few resources available to help with that...

Sunday, June 29, 2008

SPREAD OUT!

If you’ve ever seen rec-level youth soccer led by volunteer coaches I’m sure you’re familiar with this scene: a knot of kids surrounding the ball in a swarm, kicking furiously with parents cheering on. Eventually one or both of the coaches shouts “spread out!!” Usually it’s at the same moment that the ball escapes the swarm, spurring a mad dash to form a new swarm…

After a few years of this, as a youth coach I finally promised myself I’d never use that phrase again. Besides the fact that it never works, there are a couple of other issues with it:

  • It’s an instruction without accountability: no player can accomplish it on her own.

  • You can do exactly what is asked without having any impact on helping your team win. In fact, during one of my games it went the other way -- I’ve seen our defense part like the red sea and open shooting lanes for the other team. Ouch!

  • Instead, I prefer a different phrase that’s just as short and to the point:

    GET OPEN!

    Sure, it’s still an instruction delivered to the whole team, but it enables accountability in a positive sense. You can identify and praise the kids who do it, and follow up with those that didn’t hear/understand what to do. And when kids recognize and respond, it helps the team get more shots and who knows … even score on occasion. As an added bonus I started counting the number of passes made by the team during each quarter. (Hawthorne was right … measurement motivates!)

    Connecting this back to information security, the key takeaway is that it’s possible even with distributed virtual teams to develop a capacity to adjust to unforeseen obstacles without building in excessive communication and coordination overhead. But efficient teams aren’t necessarily the result of teams with a high level of security domain knowledge (CISSP, GIAC, etc.) Sure, those skills are as critical as the soccer equivalent of dribbling and shooting -- but good things really start to happen when security processes collectively orient themselves around meaningful measures.

    Clear goals – decomposed into individually achievable contributions – measured with simple, easy to gather data - and reported internally / externally to both team members and stakeholders are the key to preventing knots and swarms.