8 Keys To A Sane Security Strategy

Datamation content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.

Well, it’s finally happened: security and its first cousin, privacy, are now household requirements. Ignore them and you’re toast. How did this happen so fast? Blame it on distributed computing and the distributed steroid known as the Internet. As business models moved into cyberspace, we found ourselves facing new threats. We’re now surrounded by security and privacy technologies, officers, consultants, and regulators.

Let’s look at eight major elements of a realistic security strategy.

1. Business Strategy Linkages
All decisions must be passed through the filter of your business model. If a model doesn’t exist, you have to help your company develop and validate one (or more). If you can’t get the organization to invest in business modeling to the level where an optimal security system can be installed, make minimally acceptable security investments until the models are clarified.

Minimal investments include barebones authentication, authorization, administration, and recovery technologies. They also include a privacy policy and technology that will comply with privacy regulations.

2. Policy
You have to write it down. All of your security and privacy policies and procedures must be codified, communicated, and updated on a regular basis.

Your security policy need not be a bible, but it needs to be specific enough to reduce ambiguity. Rather than spend two years writing a perfect security or privacy policy that covers all aspects of your security environment, spend much less time and write one that works.

Make sure that you communicate the policy and offer training around it. If you cannot write a credible one in-house, then outsource it. At a minimum the policy should include:

Data access policy
Applications access policy
Network access policy
Software policy
Privacy policy
Business resumption planning policy
Systems design & development policy
Risk assessments

3. Authentication
Passwords work, but they can be expensive to administer and complicated to use on a regular basis, especially if users must remember multiple passwords.

If your password policies are well developed (for example, requiring users to change them every 30 days or so, or the systems automatically deny them access) then they might work for you in the long run. But if they are complicated and cumbersome to manage, you might consider alternative authentication methods, tools, or products, such as smart cards and biometric devices.

Single-sign on remains a worthwhile objective. Take a look at the available tools and the processes that support them. As we deploy more and more networks and users traverse networks and applications, you’ll need single-sign on capabilities.

Make sure you investigate the range of firewall technologies available since theyre changing all the time. Note the trend to embed more and more functions into firewalls, including lots of flexible authentication (and authorization) techniques. Over time, you should be able to off-load lots of functions onto your firewall.

4. Authorization
Once users are authenticated, they need to be monitored according to a pre-defined authorization schema. Access to networks, applications, and databases needs to be defined, and individual and classes of users need to know where they can go and what they can do once they get there.

5. Administration
All of this stuff is great until you have to support it. All security and privacy policy, authentication, authorization, and recovery requires administration. Make sure you ask about administration each time you consider a method, tool, technique, or process.

Develop metrics against which you can track the effectiveness of your administrative procedures. Track the data over time to determine the cost-effectiveness of whatever administrative processes you put in place.

Some basic administrative reports include:

User Sign-On Error Reports
User Policy Violation Reports
Resource Activity Reports
User Access Reports

6. Recovery
Recovery is as essential to security as authentication. Make sure you don’t short-change your security strategy by under-cutting investments in systems recovery and business resumption planning.

Business disruption and resumption planning simulations should be conducted on a regular basis — at least twice a year — to determine if your policies and procedures will actually work when a major business disruption occurs.

7. Support Services
This is tricky. Unless you have a lot of in-house security talent, you might have to look outside for end-to-end security integration. This decision must be made carefully, since theres a tendency to think that the in-house staff — who may have managed security in a host-based, data-center-enclosed environment pretty well — can manage a growing number of distributed applications that link employees, customers, and suppliers.

The range of skills must be broad and deep. You’ll need to make sure you cover all of the bases, and cover them well. The key is the integration of the services into an adaptive solution. If your security strategy consists of lots of elegant pieces that don’t fit well with one another, you don’t have a viable strategy.

The basic elements of a business resumption plan should include:

Plan Activation Policies and Procedures
Individual, Group and Team Recovery Policies and Procedures
On-Site/Off-Site Resumption Policies and Procedures
Administrative Policies, Procedures and Responsibilities
Contingency Planning

8. Enabling Technology and Issues
There are at least six enabling technologies you should track:

Firewall technology
Anti-virus technology
Certificate authority technology
Biometric technology
Encryption technology
Privacy compliance technology

These technologies enable your security strategy. You need to assign resources to track developments in the technologies and the products they support.

While there might have been some skepticism five years ago about declaring distributed security a core competency, today the opposite argument should raise eyebrows. It’s imperative that you understand the technology and how it interacts with your business model, applications portfolio, communications architecture, and other dimensions of your infrastructure.

Privacy will become increasingly important and increasingly the focus of government regulations, making it the object of computing and communications standards. Pay close attention to these trends, since the flip side of business security is personal privacy.

A Security Requirements and Planning Framework
A set of processes, methods, tools and techniques together constitute your security strategy. You need to ensure that you have technologies, products, and services for all six of the following categories: policy, architecture, authentication, authorization, administration, and recovery.

It’s vital to complete all 18 elements (technologies, products, and services for each of the six categories), since security must be top to bottom and must be supported by products and services.

Change is inevitable here. Make someone accountable for developing security scenarios for two and five years into the future.

Without question, you’ll have to deal with security as you move toward e-business — that is, toward dispersing your employees, attracting and serving customers, and connecting your suppliers. The threat of information warfare must also be acknowledged.

But much more importantly, you need to let go of the notion that security is a “step” to take when designing, developing, and deploying networks and applications; or that security can be managed by lots of tools and techniques surrounded by distinct processes.

While these notions are theoretically correct, they miss the long-term point: security is not a part of a network or an application, it is the network and application. In other words, security is as much a part of a network as a router or switch, or as much a part of an application as a user interface or database. When you stop looking at security as a disembodied part of your network and applications architecture but as an integral ingredient in an otherwise complex soup, then you achieved the next level of distributed applications development and management.

Next month we’ll look at support.

Steve Andriole is the founder and CTO of TechVestCo, a consortium that focuses on optimizing IT investments. He is a former chief technology officer of both Safeguard Scientifics and CIGNA Corp., and his career began at the Defense Advanced Research Projects Agency, where he directed cybernetics technology.

(Check out Paul Desmond’s recent security column, Taking A Bite Out of Computer Crime.)