A close friend of mine just got moved from financial services executive management to the CSO role within her organization. My friend is smart and has more degrees than a thermometer. She doesn't know much about IT security, however -- except that her company isn't doing it right.

We can debate the merits of appointing a nonsecurity person to the head of a security team, but sometimes better management is exactly what is missing. As long as the key people under her handle the technical leadership roles, the combination might work out well. If she is as smart as I think she is, she'll pick up the pertinent facts and pain points pretty quickly. She's not the type to pour all her resources into the first major emergency or believe every vendor's sales pitch.

[ Need some more career advice for your IT security role? Make a top 10 security list and think strategically. ]

She asked me what she should concentrate on initially, to reduce security risk. Without knowing a single detail of what she and her company faced, I gave her the following advice.

Remember, computer security is all about the data. We don't do everything we do to protect users or computers or software. We do all it all -- including protecting users from themselves -- to protect the data. When someone mentions a security problem or remediation, think about how it affects the data involved.

Define requirements and gaps. Start by defining the broader problem. Document all relevant business, legal, and regulatory requirements. Sometimes this is led centrally, top-down, and sometimes each sub-entity in the enterprise has different requirements. More often it is a combination of the two approaches.

After defining the requirements, identify the gaps. Where can the current processes and team be improved? What's missing? What's being done right and who is involved? Often, interested parties can be entrusted to improve other processes. Bring in senior leadership, midlevel managers, IT, end-users, and the necessary ancillary departments such as legal and auditing.

Each gap should be threat-modeled and evaluated for security risk. Calculations for security risk need to include real risk, potential incidence of occurrence, and potential damage costs. Gaps with the highest security risk should be closed first. Of course, you can't forget the political layer. Sometimes you must do a project simply because someone above wants it done.

Determine costs and goals. Now that you've identified the security risks and potential damages of each gap, determine the cost to remedy each problem. If the price for remediation outweighs the potential damage, perhaps it isn't a project to worry about. More realistically, you'll usually have more goals and potential projects (and projects already in process) than you can complete in a given time period, so rank by criticality.

It's important to tie each project to the security risk it will address and set expectations. Nothing is more embarrassing than spending tons of money to remediate a particular threat only to have it occur the next day -- been there, done that.

Develop a plan. Using the information you have, create short-, mid-, and long-term goals and projects. Tie each project back to the enterprise's requirements and strategic direction. Report your strategy and tactics to senior management. You'll need senior management's approval and backing to do the heavy lifting that is required when security initiatives start to conflict with operations.

Create and use metrics. When you are engaging with executive management, you need to summarize the current state of the security union. How many security incidents has the company suffered? What is the cost per incident? How many malware attacks? How many compromised Web sites? Metrics and pie charts may be boring, but they are lifeblood when arguing and educating senior management. Pick metrics that are easy to measure and that encompass the security risk to the environment.

Inventory the environment. When thoughts turn to inventory, most people think about counting the number of computers, platforms, and other devices. That's a given. But good security leaders need to understand the environment they are being tasked with securing. Start by documenting every network ingress point. This should include Internet access, VPN connections, dial-in access, WAN connections, partner links, and so on.

Next, inventory and classify the various user classes. Who needs to access the data you are storing? Typical user classes include internal users (privileged and nonprivileged), external users, business partners, vendors, regulators, and monitors. The general idea is to figure out the main classes of users that need access to your data.

Locate your data. List all the places where data resides, on what servers, and in what locations. How many databases, what types, and where are they stored? What are the backup media types, and where are those media devices stored? Are users allowed to store data on personal removable media (USB memory devices, portable hard drives, burnable DVD drives)? If not, do they do it anyway? This is a tough task. Who really knows where all their data is? But the idea is to take your best guess to use as a starting point.

Classify your identified data. You can make up your own categories or use very generic terms such Public, Private, and Confidential. If a single database, without logical separation, contains data of mixed classification types, mark the entire database as the most sensitive level.

Create security domains. With all the previously collected information, identify the various security domains -- logical or physically separate paths between different types of user classes and the data they need to work with. In very simple examples, outsiders reliant on public information should not have access to private and confidential data. Most vendors should not have unfettered access to an entity's private and confidential data. IT troubleshooters and staff should not have access to executive compensation figures. Security domains can be created using physical separation, firewalls, routers, Ethernet switches, VPN protocols, database controls, encryption, and a host of other tools and methods.

Commence the security remediation cycle. Once you have a good understanding of the environment, projects, and goals, a typical security remediation cycle might go something like this: First, inventory the existing or future objects, such as computers, users, groups, and so on. Next, minimize how many objects you need to meet business requirements. Third, secure the remaining objects, however they may be defined by your projects and goals. Finally, manage the lifecycle of the remaining objects.

Manage the object lifecycle. Object lifecycle management includes creating or improving the processes and controls around requesting and creating objects, managing object changes and moves, and documenting decommission of objects (so that they don't hang around forever). Adds, moves, changes, and deletes should have change and configuration controls built around them. Management should including monitoring, alerting (that is, what is an actionable event?), and auditing.

I always end my computer security spiel with this: A significant amount of any entity's security risk can be decreased by preventing users from installing malware (however you accomplish it), excellent patching (both OS and applications), and getting SDL (Secure Development Lifecycle) into any internal programming or development process. Preventing malware installation will keep out the vast majority of today's client-side attacks. Implementing SDL will decrease server-side risk, and better patching helps both.

When I got through, my friend asked sarcastically, "That's all?"

Yeah, welcome to our world.