The year is still relatively young, which usually means that at some point, we all sit down either alone or with a group of trusted friends and colleagues, and make up lists of issues we intend to resolve over the course of the next 12 months.
Unfortunately, however, after having spent far too many roundtables, brown-bags and Chinese-take-out-meetings in front of the PowerPoints, whiteboards and forecast spreadsheets, the only thing we actually 'resolve' is that our anxieties will heighten greatly by end-of-Q1, when we realize our lists hardly made a dent in the work we actually ended up doing.
The same is generally true for those of us with an IT security bent. Most of the things we list as 'issues' to resolve by year's end are phantoms left to dry on those whiteboards. And by mid-year, a lot of the issues we were trying to address in January remain un-addressed by mid-year.
The general problem: Most management teams lack the internal expertise or resources to accurately identify the starting point for addressing security issues. Moreover, many fall victim to the next security vendor's marketing hype that shows up on an annual buyer's guide, hawking 'UltimateSecurity.com's' SilverBullet 1.0.
But before actually buying or deploying the new magic, security management teams should consider the following 10 probing questions:
Question No 1: "Is our staff sufficient to address matters pertaining to securing our business (and can we afford more people)?"
This question isn't just about the headcount numbers game, there's a level of aptitude that should be considered as well. Here are some related questions: Are members of your IT staff competent to understand the aspects of securing your environment? Do they understand, or can they adequately address, the balance of technology and support associated with securing your business versus the assets you are protecting? Did your staff actually want the job of being the 'security go-to' people, or did they draw the short straw in some management shuffle? How reasonable is it for you to employ a handful of people to watch over a multi-site, possibly multi-national, computing infrastructure?
Okay, you get the picture. There's more to a security team than headcount. But headcount can't be compromised for the sake of budget - unless you're planning to augment the team with outside help.
Question No 2: "Do we have top-down endorsement for security issues?"
How much do the folks on the top floor know about securing those assets they're building for the company? Also, do they fully understand their liability? Many IT security managers have commented that their job was half spent on diplomacy within the halls of the senior staff. It's important to note that the executives - particularly the CEO and CIO - must agree to the level of empowerment you need to affect policy change and what you're planning to build on.
Question No 3: "Does everyone within the organization understand the need for security (beyond the locks and doors)?"
When you think about the matter of awareness and risk in your business environment, are there gaps? Consider that there are probably five levels of audience you have to manage from a security standpoint. I call it the 'Five-front Buy-in Battle.'
Shareholders: They're reading their favorite financial publication, and there's a blurb about how Company 'X' just got hacked or lost three days of operation because of a new attack. Mr. Shareholder knows this company. He's invested heavily in the competition, and so naturally, he's concerned about his investment, and lobs a call into the CEO - seeking solace from his morning read. How will the conversation go?
Executives: I once saw the CEO of a major company, in front of the entire staff at an annual meeting, fumble with a projector, trying to figure out how to launch his PowerPoint. "Is somebody working on this?" he asked through his microphone. It was a good thing his CTO was standing near the 'On' switch! Simply put, executives are in place to ensure shareholder confidence and overall direction of the core business. They may not be completely aware of the risks to their business, or understand how the process works to address those risks.
Management: Here's a group of folks whose primary objective is to ensure the safe operation of the business at a department level. Their concerns focus mainly on productivity, consistency and individual performance. The risk here? You, as the security 'Go-to' might be introducing procedures that inhibit those focus points or 'pet projects' harbored by those managers.
System Administrators: Everybody knows these guys. They are the ones who are called in when the lights go out on our screens, when the files don't seem to magically pop up on their own - heck - when the soda machines don't work! The system or 'network guys' are the critical links between an organization's assets and operation, and their main concern is keeping things running and not introducing something new that might cause performance problems. So determining what kinds of technology are acceptable in those sacred networks will be a major concern to them - and a potential challenge to your objectives.
General Staff: "You mean I have to shut my computer all the way down before going home and at lunch time?" Remember the Weakest Link isn't about the people in your organization, it's about the devices they leave vulnerable to exploit. This is a matter of education, and again, the notion that 'security everywhere' be implemented from the highest ranks all the way through to the front desk.
Question No 4: "Do we have a detailed corporate security policy (or any policy at all)?"
People often cringe at the sound of 'policies and procedures.' In many cases, such things are akin with terms such as 'red tape,' and 'bureaucracy.' However, in the case of a 'security policy,' nothing could be more important to the safe operation of a business. Security policies outline certain controls and mandates that should be globally distributed and understood. Matters such as password strength, off-hours Internet usage, file access and procedures for deploying new technology are all components of a sound security policy. Simply, a security policy provides the charter for the organization's security posture.
Question No 5: "Do we currently have automated controls in place?"
If you already have security technology in place, it's important to understand its impact and limitations in your environment. Many times, often due to turnover in staff, transfers of power and other random acts of corporate deity, IT managers and their bosses may not be either aware of what controls that have been purchased (not to mention, actually deployed), or how effective those controls are. In such cases, you might not even know where to find these controls. This is a good place to consider outside help to assist in any reviews of your environment and those mystery technologies.
Question No 6: "What are the measurements we use to evaluate the success of any policies and controls that we do use?"
This question is borrowed right from the U.S. federal government infrastructure. It's called, 'Checks and Balances.' On the one hand, you have a security policy. On the other, controls by which to provide certain enforcements of those policies. But what mechanism do you have in place to evaluate those controls or review the policies? Technology changes rapidly, and so will your operational requirements. For example, there are numerous occasions where organizations will buy, deploy and rely on security controls, such as anti-virus tools or IDS controls, only to forget to keep their signature and policy definitions current. Consequently, these controls lose their effectiveness. Providing a regular assessment on your environment means you're keeping your system, and the security measures you have chosen, accountable. Yesterday's vulnerabilities may or may not be of serious consequence to your network today, and the occasional 'fine-tuning' will help keep both your policies and controls updated.
Question No 7: "Have we taken the basic steps needed to avoid monumental security problems (do we know what those steps are)?"
Before you ever have to invest a dime into your security infrastructure, there are certain actions you can take to reduce risk of exposure and threat. For example, many systems are shipped with certain default services (such as Echo, CharGen, etc.), which are easy targets for exploit. Unless you have specific needs relating to these services - and they're usually isolated and limited - it's a good idea to remove these types of default services. Doing so greatly reduces the risk to those generic, high-impact denial-of-service attacks. Also, controlling dead accounts (i.e., Guest, Test, etc.), as well as accounts pertaining to administrative access (e.g., Admin, Root, etc.), can also reduce the risk of the bad guys getting in. And be sure to check those former employee accounts as well. It's one thing to disable a former colleague's account, but you eliminate the risk of that account being exploited when you remove all traces of the account from your environment.
Question No 8: "What is our procedure for assessing risks to our environment - especially as we plan to expand our business?"
Assessing risks to your business is not an easy process. We're not talking about simple financial losses. Rather, you have to consider the actual assets relating to trust, manpower, knowledge base, and recovery. Some security experts look to the 'Triple-A' method when evaluating risks:
- Acceptance: in which some risks are affordable to accept, and that providing sufficient protection from those risks outweighs the assets being protected.
- Avoidance: it becomes cost-efficient and necessary to deploy a certain level of deterrence to protect from a particular risk at all costs.
- Assignment: often a cost-focused effort, this implies that an organization transfers a particular risk, in the unlikely but possible event that an event occurs, such as having car insurance in case of a wreck. You still drive, but should an event take place, you have assigned a financial liability to that risk.
You also have to identify what assets you are concerned with, and evaluate the risks to those assets. It's important to note that assets and their respective risks will vary, so the controls and processes you deploy to address those assets and risks will likely vary in degree of intensity.
Question No 9: "Do we have formal procedures for managing security incidents?"
Okay, the big day comes, and the bells sound. You've incurred an incident. Now what? This is one of those rare circumstances where it actually makes sense to put that cart before the horse. If your organization has taken the necessary precautions to avoid likely incidents, it doesn't guarantee an incident won't occur. However, you can greatly reduce the impact by having been prepared. Perhaps the single most important element for your team to consider at this point is an incident response and handling procedure. For example, what is the process for contacting the media? What information will they reveal about the incident, and what will they be required to protect?
These procedures are not very difficult to prepare - as long as you have done your homework in advance. For example, you can use your security policy as the framework on which to build an incident response procedure. Simply add "In the event of ..." prior to each component of your policy, and define a procedure for action. It's not that easy, but this process will carry you a lot further to reducing damage in the event of an incident.
Question No 10: "Do we have (or need) a dedicated incident response process or team?"
You've got the policies and the procedures, now all you need to consider are those people responsible for executing the processes. Do you have a team of folks within all levels of the organization, whose secondary responsibilities might include coordinating a response and containment procedure for an incident? Who will be your designated spokesperson to the outside world? Who has the keys to the storage facilities, where your backups are kept (assuming you have included backup procedures as part of your policy and incident response and handling)?
That's it, ten basic questions - any of which could be expanded into full-scale presentations, articles or case studies.
The bottom line to all of this? Securing your infrastructure will definitely require a balance of technology, services, processes for operation, and a skilled team of people to manage the risks. However, you can do a lot to prepare your environment before calling the vendors, by taking the extra time to plan for, understand, manage, and reduce those most commonly exploited risks. Then, when you're ready to talk, we'll be here for you.
Drew Williams is the senior security services analyst for North America for Symantec (www.symantec.com).
