|
Section |
|
|
1 |
This section describes a methodology for designing a robust and long lasting Security Architecture. There is a well structured and logical process that ensures that the resulting security architecture will be successful. Many issues must be considered, and they are listed below as a checklist. The following is based on practical experiences.
There are many ways to define the term Architecture. We choose to define Architecture as a template for a collection of technologies which work together constructively to result in the desired business functions. The security architecture addresses the need to secure the computing infrastructure. It describes the security technologies that fit together to secure this infrastructure. In this context, the term ‘security technologies’ is used to define systems like: smart cards, firewalls, e-mail content scanners, etc.
A good architecture will minimize the overlap of functionality between multiple technologies and will ensure that there is no missing functionality. Whenever possible, the architecture should be flexible enough to allow the designers to minimize of the number of vendors for the required products.
A good architecture should be based on existing or evolving standards. This allows the use of a wider range of products to implement the architecture. In situations where there is no existing standard, then attempts should be made to work with other interested parties to form a consensus for a de-facto standard. For most corporations, security is not a strategic functionality. Rather, security is a critical and required part of the infrastructure. Most corporations would benefit by sharing their security technology with their business partners. In fact, it can even be argued that corporations can benefit by sharing this technology with their business competitors. One reason is that vendors of security products will develop more suitable products when a large industry segment collectively demands a consistent set of security requirements.
A good architecture will be consistent and even. The typical corporate computing environment consists of many different ‘zones’. Examples of zones are: Unix based hosts, Windows clients, Oracle database servers, Web servers, etc. A typical application or business process may span many zones, i.e. the distributed application may have components on many systems. The level of security should be consistent in all zones. The application would be vulnerable to attack if the security in any one of the zones is weak. Yet, having excessively strong security in one zone is usually not sensible because stronger security usually comes at a price. The price would be both in dollar cost and in user convenience. The architecture should bring consistency to the security of the infrastructure.
A good architecture should be proactive, and not reactive. It should foresee and allow for new technologies and applications. It should not be driven by any one technology or application. It should not be based on any specific business need, but should encompass a broad vision. In fact, the architecture should evolve so that it continually leads the availability of new technology by a couple of years. This can only happen if the security requirements are clear and the security functionality is broken into distinct modules.
The Security Architecture is developed using a deliberate methodology. First, a set of security policies should be developed and validated. The policies should be based on business and regulatory requirements and also on the installed computing base, the network infrastructure and the existing applications. Next, a “Security Vision” is developed based on the policies. The vision describes a high level functional view of the security systems as seen by users, administrators and by system developers. Next, the “Security Architecture” details the technical specifications of a combination of systems and software that implements the security vision. The Security Architecture has a global component and a platform specific component. The global component addresses platform independent and cross-platform issues. The platform specific component addresses specific vulnerabilities that are unique to that platform. Examples of ‘platforms’ are: Unix, NT, Sybase, etc. The “Gap Analysis” is the difference between the current and desired states. The “Implementation plan” is an engineering project plan that describes the steps to accomplish the architecture. It may specify a series of phases. Lastly, it is very important to review the state of security periodically and make necessary adjustments. This ensures that the security stance evolves to address new threats, new advances by security vendors, new requirements and the viability of the current implementation.
This periodic review is shown as the feedback path in Figure 1 and reflects the need to continually fine tune the policy over time to reflect what is practical to implement and enforce, and what is not practical. It factors in the experiences based on the technical limitations of the system, social issues relating to the users and on new business requirements.
Figure 1 will be used throughout this note to describe various aspects of the work involved in developing the desired security architecture. Each module will be described in detail.
Note that, ideally, the set of available products should not influence the security policy. However, we feel that the security policy should be something that is practical, enforceable and convenient. It should be based on current technology and should evolve with it.
Based on industry surveys, most business units have the following broad requirements:
Security: The data and other resources should be secured
to retain an edge over competitors. Also, only authorized clients should have
access to data and resources so that revenue generation is not impaired. The
specific mechanisms required for this purpose are:
Data privacy and confidentiality
User authentication and authorization
Protection against ‘denial of service’ attacks
Convenience: Security should be transparent. Business
processes should proceed unhindered. Failing that, security should be as
convenient and unobtrusive as possible. Some details in this area are:
A significant amount of support should be provided to BU
administrators and users as they try to deploy and use their applications in a
secure way. Toolkits should be provided for developers so that they can
easily conform to security policy.
In some cases, temporary variances should be granted to the
applications that do not currently conform to the security policy. This will
allow the application owners to assess the risk and to proceed with their plans
if the risk is acceptable for a short time.
Auditability: Business processes and applications should
survive audits. These audits would be performed by internal or external
agencies. Audits can be very comprehensive and can cover a wide range of
issues, like regulations covering customer confidentiality, Chinese Walls, and
authorization limits. Auditors like to look for mechanisms that address:
Detection of abuse
Prevention
Recovery
One way to gather the appropriate security information and business needs requirements is to organize and facilitate a set of working meetings and data gathering workshops among the various groups. Examples of relevant groups are: the architecture design team, application developers, security administrators, network support groups, auditors, data owners, and appropriate user groups. The information gathered will be used to assist the architect in determining and describing the detailed security and technical requirements necessary to identify any weaknesses with the existing infrastructure.
Threat analysis is an important aid when defining the security policy. A threat analysis is a process where all possible threats to the computing infrastructure are identified. A list containing these threats and the severity of each threat is created. Threats can be accidental (unintentional) or deliberate (an attack.) Analysis is an ongoing process based on new information obtained from industry news; subscriptions to various reporting services, ongoing research, experience, etc.
Examples of accidental events are:
Improper editing of a configuration file causes outage of a
system or application
Mistyping of an e-mail address causes sensitive information to be
sent to the incorrect recipients
Due to shortage of disk space on a server, a truncated report is
sent out to a client, who then makes bad investment decisions based on
incorrect information originating from the corporation.
Examples of deliberate events are:
An attack on the firewall
Snooping of client investment data for personal use
Developers have access to production hosts and directly modify
software on these hosts, causing the application to crash. This indicates a
lack of business integrity for the software.
It is important to develop a list of potential threats and non-threats. The management and technical staff of the target corporation should carefully review the list. This establishes the degree of “paranoia” associated with the corporation and its staff.
The following is a partial list of risk areas that should be examined.
IT Infrastructure:
OS configuration and hardening
Servers
Desktops
Laptops
Home Computers
Network FAX Machines
Printers
DNS servers & Domain controllers
File Servers
Video Conferencing System
Voice Mail System
Firewall & Proxy Server
VPN
Remote Access System
3rd party access to network
LAN, Switches & Routers
Wireless LAN
WAN
Backup & Storage
Card Key Physical Access system
Infrastructure Software & Applications
Virus Protection System
Event & Alert logging & consolidation
Intrusion Detection
Host Based
Network based
URL control & logging
Email content scanning
Authentication Mechanism (e.g. SecurID)
Network & System management system
SQL Database servers
Lotus Notes email system
Lotus Notes databases & replication
Change management software
Bloomberg
All internally developed applications
Security Maintenance Procedures
Periodic penetration testing
Log auditing and analysis
Retraining of key personnel
Security Procedures
Employee termination procedure
New employee procedure
Consultant / Temp termination procedure
Policy exception tracking
Annual review of access
To perform a qualitative analysis of the state of security, we will need to estimate the probability of occurrence each of the threats. We will also need to estimate the business impact of each threat. One way to quantify the impact is to estimate a dollar cost associated with the business lost due to an attack based on the threat. This is described later.
Threat Analysis involves examining the existing security infrastructure, policies and procedures to identify potential security risks. Administrators and users should be interviewed to gauge their attitude towards information security. An evaluation should be made of the potential for security breaches that could adversely affect the financial and business image of the target corporation and the integrity and availability of business services. All the identified weaknesses should be documented and will be used as input to the architecture design phase. During this phase additional relevant and appropriate security requirements should be identified.
As a result of the meetings and security analysis, a detailed document that describes the current security stance should be produced. The document should also contain information regarding all identified weaknesses in the existing implementation. Technical staff and management should review the draft of this document. Their feedback should be incorporated into the final document.
A security policy is the starting point for creating a secure computing system. It is a set of rules stating what is permitted and what is not permitted in a system during normal and emergency operation. It describes what is to be made secure, and defines the degree of security. The policy should balance between productivity needs (user convenience), cost of implementation (the budget), the threats to the assets, and the level of risk protection required by the business. The security policy is often a political consensus reached by corporate management.
Each policy should define:
What resources are we trying to protect
Which people do we need to protect the resources from
How important is the resource
Who authorizes users
Guidelines or rules for exceptions (variances) to the policy
and, most importantly, an explanation of the rationale for each
policy.
When the security policy is defined, it is important to realize that the rules affect what security mechanisms are to be selected for implementation. This makes it important to define a security policy that enables the design of a correct but also a practical and usable system. A policy that cannot be immediately implemented and enforced is relatively worthless. A correctly designed security system is like a locked door to a building: if the door and the locks are good enough, most intruders will leave the building alone. However, if intruders really want to get in, they will be able to do that no matter what locks there are on the door. The policy should ensure that the cost of breaking in comparable to the value of the resources inside the door. Also, if the locks are not easy enough to use, there is a tendency not to use them for their specific function (at least for short periods of time,) and that can create a situation an intruder may use. The same rule applies for computer security: the tools used to enforce security must be good enough and easy enough to use, to be accepted by the users of the system. Any action, intentional or unintentional, that violates the rules stated in the security policy is a security violation.
The Security Policy should be customized for each situation, since each Firm has a different balance of budget, threat environment, tolerance for risk and desire for convenience. For example, a set of policies developed for one bank will not be suitable for a different bank, even though they may be similar is size and have similar business strategies. The culture within the two banks may be different, leading to different targets for user convenience and appetite for risk.
A suitable Security Policy can be derived from other existing policies. Potential sources for policies are:
Policies from other similar Firms
Existing policies in other departments
Prewritten policies, e.g. from the Charles Grissom Woods book,
SANS, etc.
When drafts of the policies are completed, they should be reviewed by:
Human Resources and the Legal staff
The business units affected
Industry experts, to certify that the policies completely address
regulatory requirements (if any.)
Lastly, the policies should be updated based on comments received and published within the Firm. At least one person should be given the responsibility to continually maintain and revise the policies. To stay abreast with changing business needs, all policies should be reviewed and revised once every two years, at least.
A Security Vision describes a high level functional view of the security systems as seen by users, administrators, data owners and by application developers. It does not usually describe the actual mechanisms. Together, the following security services should be covered:
Identification and Authentication
Authorization and Access Control
Confidentiality and Integrity
Non-repudiation
Monitoring and Logging
Administration and Re-certification
The following diagram depicts the security services, the mechanisms that implement them, and the objects to which they apply. Note how Architecture is shown sandwiched between Policies and Compliance.
Figure 2: Security Framework
The security vision should cover the following aspects:
Tight system configuration: Each desktop and server system is
configured to disallow dangerous and ill-advised activities. Periodic checks
will be made to verify proper configuration.
Reduced user sign-on: The user logs in once to the desktop and
thereafter has easy access to all other authorized systems and applications.
Tools will be made available to developers so they can build secure and
compliant applications. The systems to which users will have Reduced Sign-on
access includes:
WWW based applications
Mainframe, TSO sessions and CICS
Unix hosts and applications
NT and Windows hosts and applications
Desktop screen savers
Local disk encryption (if installed)
Sybase servers and applications
e-mail & other groupware applications
Virus detection & correction software installed on all
vulnerable user desktops
Sensitive data (especially passwords) are to be encrypted on the
network.
There will be reduced points of administration and control for
user definition and authorization.
User addition and deletion is automated and driven by batch input
from Human Resources.
Role based authorization. Authorization profiles to simplify
administration.
Multiple applications that can share the same authorization
rules.
Toolkits are available to developers on all platforms to build
secure applications that interoperate between platforms. Toolkit supports
authentication, authorization, audit, encryption, and integrity protection. A
standard API (such as GSSAPI, CDSA or CAPI) will be used.
An enterprise wide public key infrastructure will be available to
enable various next generation security functions. The PKI should be selected
carefully so as to allow a maximum number of applications to use it.
A firewall that secures the network perimeter from undesirable
users. Firewalls may also be installed to segment sensitive areas of the
corporate network.
Intrusion Detection Systems to watch for attacks from inside and
to detect attacks that somehow get through the firewall. IDS systems also
check for application level threats, such as e-mail, HTML and Javascript based
attacks.
Activities on sensitive hosts will be monitored and audited.
Host based intrusion detection systems will be deployed on key hosts.
Secure access provided for users who access the corporation’s
networks remotely. Access is supported through dial up lines (POTS & ISDN)
and also through the public Internet.
VPNs will be supported for secure remote access over the
Internet, and also to segment especially sensitive applications in the
corporation’s internal network.
Encryption will be provided for data transmission and for data
storage. Authentication and non-repudiation services may also be bundled with
this service.
All applications and systems generate standard logs and alerts.
Logs and alerts are delivered to a centralized location. Alerts are
automatically processed and personnel are notified as necessary. Weekly
rollups of logs are sent to interested parties.
Development and production environments will be properly
segregated.
The Security Architecture provides a plan for the realization of the above vision. It comprises of a list of components that leverage and build on each other. It has two parts: a global part and a platform specific component. The global component addresses platform independent and cross-platform issues. The platform specific component addresses specific vulnerabilities that are unique to that platform. Examples of ‘platforms’ are: Unix, NT, Oracle, etc.
The global security architecture includes the following aspects:
Authentication Services
Kerberos 5 (for Windows 2000 / XP)
Public Key Infrastructure
Two-factor authentication is used for remote access and for high
value applications (including Firewall maintenance access.)
Single signon
Authorization framework
User and group administration
Event logging and audit facility
Firewall and DMZ architecture
Remote access architecture
Virus protection strategy
Intrusion Detection strategy
Email security
Secure Application Programming Interface standards
The platform specific architectures include Baseline security and OS hardening for each platform:
Mainframes (MVS) & Midrange (AS/400)
Unix & Linux
NT servers
Netware servers
PC & Unix desktops
Database servers (Oracle, Sybase, DB2, …)
Other major application zones (SAP, PeopleSoft, …)
The following diagram shows a “landscape” or “mosaic” of a few security services. It shows various layered modules, the interfaces to them and their interdependencies. Note that the details of this diagram will differ from situation to situation, and from company to company. The purpose of this diagram is to show potential overlaps or holes in security functionality. It is also a useful diagram to show management the complexity of the security infrastructure. A few bubbles are labeled with specific product names to help viewers relate the products that they are familiar with to specific security services. Product names are shown within quotes. Whenever possible, interfaces are marked with the names of the protocol or API.
Figure 3: A Mosaic of Security Functionality
The proposed architecture should be carefully reviewed by the corporation’s staff to verify that all aspects of the IT architecture are covered. The following groups at the corporation should review it.
IT architecture team
Key application developers
Key administrators
Selected user groups
Network support staff
The goal will be to verify that the security architecture is both complimentary and compatible with the overall IT architecture. The information gathered during the initial phases of the project should be used to design a security architecture that has the appropriate security controls to preserve the integrity, confidentiality and availability of the target corporation’s information and computing resources.
|
Section 2 |
The previous section dealt with the technical aspects of designing a suitable security architecture. This section deals with the strategic aspects of implementing and maintaining that architecture. Usually, there are two distinct phases for implementation: the initial deployment, and the ongoing maintenance. The initial deployment is accompanied with lots of enthusiastic activity and generous budgets for the purchase of new products. After the honeymoon period, the maintenance phase is usually marked by new security threats, declining budgets, and escalating expectations from users and management. A consultant may be able to help build the initial security architecture and strategy, but implementing and maintaining the program requires a dedicated staff for persistent effort.
Once an architecture has been nailed down, the next step is to perform a “Gap Analysis” to determine how far the current implementation is from the desired state. This analysis will yield a list of projects that need to be implemented to get to the desired state. An implementation plan is a project plan that describes the phased implementation of the projects. In order to maintain business continuity, it is often not feasible to simply rip out the previous system and install the new system. It is not acceptable to disrupt ongoing business. Instead, it is necessary to define a sequence of steps. The plan should also discuss product evaluation and trials involving limited deployment. There should be a “Back out” plan in case the trial fails to meet expectations.
A Gap Analysis is a report on the deficiencies of the current security implementation. In order to generate this report, we would need two things: the agreed upon security architecture, and a clear idea of the status of the current implementation. Given these, it is relatively straightforward to step through each item in the architecture and determine the gaps. It is usually best to delegate the task of developing a Gap Analysis to an external consultant because these people will be less influenced by the politics and history of the situation. They will have less of a stake in maintaining the status quo, and will be more likely to correctly highlight the security flaws. However, the local IT department must be involved at every step, because they would have the information required to compile a detailed inventory of the current status.
To get the current status, we would need a detailed inventory of:
Network and Host vulnerabilities, as reported by a security
assessment effort.
Published security policies.
Security products that have been deployed on various platforms
Licenses and terms for each product
Available administrative and technical support for the product
A brief report of the functionalities provided by the product.
Products that are being trailed or prototyped.
Security related administrative processes and procedures.
Security configurations (e.g. Access Control settings)
The report should contain the discrepancy in security functionality and also a brief note on the suggested remedy. The report may note compensating factors that may lessen the effect of a deficiency. It is also useful to note when the current functionality exceeds the level specified by the architecture because this excess usually comes at a cost. Examples of items in a report are:
Asset Management Application
Discrepancy: Does not conform to Corporate Single Signon
architecture.
Remedy: Reprogram application to use standard security API and
corporate authentication server.
Discrepancy: Sensitive data is not encrypted between client and
server.
Remedy: Reprogram application to use standard security API and
data encryption functions.
Discrepancy: Inadequate access control on application database.
Remedy: Analyze data model and set up access controls for
individual fields and records on Oracle database. Establish group IDs on
server.
Discrepancy: Security patches not applied on web server.
Remedy: Apply patches as recommended by vendor or by
knowledgeable user groups.
Firewalls
Discrepancy: Additional redundancy is required.
Remedy: Develop new architecture that includes redundant
connections to Internet, fail-over firewalls, and load balancing.
Discrepancy: Penetration test reveals ICMP is not blocked.
Remedy: Reconfigure firewall rules.
Remote Access
Discrepancy: Password complexity rules are not being followed.
Remedy: Install & configure a RADIUS server.
Discrepancy: Two factor authentication is desired.
Remedy: Purchase & deploy a product like SecurID.
Laptops
Discrepancy: Password complexity rules are not being followed.
Remedy: Purchase and install laptop security package.
Discrepancy: Sensitive data is not encrypted.
Remedy: Purchase and install laptop security package.
A Gap Analysis would be useful during a security audit. However, at this point we are concerned about generating a list of tasks that need to be accomplished. This list is extracted from the remedies described above. If the Analysis consists of a short list, then it gives the IT managers confidence that their current efforts are working and that their ship is in good shape.
The purpose of this technique is to prioritize the tasks generated by the Gap Analysis so that the most important and feasible tasks are started first. If the number of tasks is relatively small, then it may be possible to manually sort the list by “gut feel”. The basic rules to prioritize tasks are:
Tasks that are easy to accomplish and have high visibility should
be completed first. This will improve the organization’s image during an impending
audit.
If a risk mitigation opportunity exists for a task, then that
task can be delayed in favor of other more crucial tasks.
Tasks that require large expenses may have to be delayed until
appropriate funds are available.
All other factors being equal, critical tasks which lead to large
vulnerabilities should be prioritized first.
However, the above method may be questioned by reviewers who may have a different feeling for the relative importance of the tasks. A quantitative approach reduces this variability and also helps justify the task list and schedule to management. To use this approach, we should have a Risk Analysis (as described earlier) completed. We will build on the analysis to assign more accurate probabilities to some of the risks. Next, we will estimate the dollar loss value for each of these potential risks. This process is called Risk Assessment and is described next.
With the numbers from the Risk Assessment, we now have a basis for prioritizing projects. Clearly, the project with the highest risk needs to be completed first. However, a number of other factors can be quantified and factored in. This will modify the priority list. For example,
The cost of the project will inversely affect the project
feasibility. This is shown in examples below.
The duration of the project can affect the priority in two ways.
Very short projects can be prioritized first to score some “quick wins.” Very
long projects should also be prioritized because they need to be started soon
so that they are completed in the reasonable future.
Risk areas that will be attacked at a higher frequency, i.e.
multiple times in a given period, should be prioritized higher.
Political considerations are always a reality. The bosses’
favorite projects cannot be ignored without risking the fate of other projects
(and careers.)
Additional factors may apply, depending on the situation. All of the factors can be compounded and a final score can be calculated for each project. The projects are ranked based on this score, resulting in the final prioritization. A phased implementation plan will be developed out of this list.
Every rule has exceptions. As an interesting story, we once ran into an application that was so profitable and generated so much revenue that the business manager refused to include it in our risk assessment process. We heard that losses due to customer fraud were high, but apparently the profits were much higher. That application was left unchanged. The lesson learnt was that “Business always rules.”
Risk Assessment is a refinement of the process described earlier as Threat Analysis. Its goal is to quantify the risk to a business from a given source. There will be many sources, each being a vulnerability associated with an object required for the business. There are many published methods for Risk Assessment. We describe a method that we have used and found to be quite satisfactory.
In the Threat Analysis step, we described a procedure that scanned the entire security landscape. Here we focus on only those discrepancies that we found during Gap Analysis. Stepping through each item in the task list, we will make a list of objects that are at risk and the source of the risk. For example:
Asset Management Application
Risk Source: Asset Management Application Software: Password leak
Risk Source: Asset Management Application Software: Data snooping
Risk Source: Attacks on Oracle Database
Risk Source: Attacks on Web Servers
Firewalls
Risk Source: Loss of Internet access caused by firewall failure
Risk Source: Various attacks due to improper configuration
Remote Access
Risk Source: RADIUS server (for password complexity)
Risk Source: SecureID server
Laptops
Risk Source: Laptop Security Software
We need to estimate the value of each item. One way of determining this figure is to estimate the business loss value: What is the dollar amount of the loss if the object in question is compromised using the listed attack? The loss could be a missed business opportunity due to a denial of service attack, a loss of reputation or customer loyalty, stolen business data, etc. Business owners should be involved in this step because they will be able to estimate these costs better than IT staff. For example, the costs could be as shown below:
|
Risk Area |
Potential Cost of Loss |
|
“Asset Management” Application |
$100M |
|
Software: Password Deficiency |
$10M |
|
Software: Encryption missing |
$60M |
|
Oracle Database Security |
$30M |
|
Web servers weaknesses |
$80M |
|
Firewalls updates |
$30M |
|
Remote Access |
$10M |
|
Radius Server Password Rules |
$10M |
|
ACE Server |
$10M |
|
Laptops |
$1M |
In the example above, the potential damage estimated for the situation where an attacker breaks into the application and freely transfers funds between all accounts is estimated at $100 million. If the attacker breaks into one account due to poor password selection, then the damage is limited to that account and is estimated at $10M. It is estimated that lack of encryption can permit certain attacks that result in $60M in damages. Note that these estimates are made up for this note, and can vary from application to application.
Next, we will estimate the aggregate probability of each event. One way to do this is to classify the attack and determine the frequency of such attacks. Organizations like CERT and SANS maintain historical data on various classes of attacks. The probability of the attack will be directly proportional to the recorded frequency. One should also look at the trend line of the frequency. The trend could be up, down or flat. Since we are estimating future risk, we should take trends into account. Sometimes, we may be able to estimate probabilities for related or similar attacks. We can use that data and adjust the results appropriately.
Often, we may not be able to obtain adequate historical data. In such cases, we will have to estimate the risk probability by determining the feasibility of the attack. For example, are the tools required to mount the attack readily available on the Internet? If huge amounts of computing power are required, then how readily is that available? Are the members of the staff inclined to mount such attacks? Are they technically capable?
The estimated risk probability is listed in the following table as the “Vulnerability” factor. The product of Vulnerability and Loss Cost is the “Task Criticality”. This is a direct measure of the severity of the risk.
|
Cost of Loss (estimated) |
Vulnerability (estimated) |
Criticality (computed) |
|
|
Asset Management Application |
$100M |
15% |
$15M |
|
Software: Password Deficiency |
$10M |
30% |
$3M |
|
Software: Encryption missing |
$60M |
15% |
$9M |
|
Oracle Database Security |
$30M |
20% |
$6M |
|
Web servers strengthening |
$80M |
30% |
$24M |
|
Firewalls updates |
$30M |
40% |
$12M |
|
Remote Access |
$10M |
20% |
$2M |
|
Radius Server Password Rules |
$10M |
20% |
$2M |
|
ACE Server |
$10M |
10% |
$1M |
|
Laptops |
$1M |
30% |
$0.3M |
In this step, we will adjust the Project Criticality with all the remaining factors. For this example, we just account for Project Cost. Other possible factors were listed earlier as Project duration, Attack frequency, and Political and Social considerations.
The ratio of Criticality and the Project Cost is a “Feasibility factor.” This is a number that takes into account the project’s importance and cost. If multiple factors are taken into account here, then each other factor should be quantified and multiplied by an appropriate constant scaling factor. This value is then directly or inversely compounded into the feasibility factor.
Projects are ranked according to this Feasibility Factor. In the example, Web server strengthening emerges as the top priority project and laptop security comes out last.
|
Risk Area |
Criticality (computed) |
Project Cost |
Feasibility (computed) |
Ranking |
|
Asset Management Application |
$15M |
$100K |
150 |
6 |
|
Software: Password Deficiency |
$3M |
$20K |
150 |
7 |
|
Software: Encryption missing |
$9M |
$20K |
450 |
3 |
|
Oracle Database Security |
$6M |
$10K |
600 |
2 |
|
Web servers strengthening |
$24M |
$15K |
1600 |
1 |
|
Firewalls updates |
$12M |
$30K |
400 |
4 |
|
Remote Access |
$2M |
$20K |
100 |
8 |
|
Radius Server Password Rules |
$2M |
$5K |
400 |
5 |
|
ACE Server |
$1M |
$30K |
33 |
9 |
|
Laptops |
$0.3M |
$20K |
15 |
10 |
Security should always be implemented in a way that is unobtrusive to the business. The only exception to this should be when there is a possibility of a threat to an IT component that can cause a severe loss. This threat should be evaluated and proven to be immediate and viable. Only in this case is it acceptable to restrict or shut down the affected business processing until a work-around is implemented. In all other cases, the deployment of security infrastructure should have minimal effect on day to day processing.
Products can be deployed in phases. Each phase can be tested and turned live individually. This will avoid the “Big Bang” situation when multiple components are introduced to the users simultaneously and a lot of confusion results. Note that administrators are also affected and this situation will require a steep learning curve on their part. For example, while deploying an authorization capability, it may make sense to first deploy the LDAP server, then the authentication functionality, then the application and lastly, to turn on authorization checking.
It may also be possible to deploy each phase to limited segments of the user population. For example, say a firm has three connections to the Internet, one each at New York, London and Japan. A planned firewall upgrade can be done first at only one site. Hopefully, this would limit any ill effect caused by mistakes to only users at that geographic location.
Each phase should have a thoroughly reviewed “Back Out” plan. Even with meticulous planning, it is possible that some small unforeseen property of the system being deployed has unacceptable side-affects, especially when the system interacts with existing systems.
Based on our experiences, here are some other tips for sustaining a healthy security program.
There is a need to dedicate a “Security Officer” for the entire
enterprise. The HIPAA and GLB regulations demand it. This would provide a
“point person” who would be responsible for incoming reports of threats and for
ongoing security activity. The absence of such a person will lead to finger
pointing and confusion during crisis.
Select a member of senior executive management team to “sponsor” the
Security Program. This will give the program the political clout necessary to
move reluctant business managers. Even though the security program may fall
under the Chief Technical Officer, it will help when security policy directives
originate from the CEO or COO. This will also be helpful to push security
initiatives through application developers.
In order to gain commitment from senior management, we would need
to periodically update them on progress and keep them informed on the threat
situation. This will improve management awareness and make them feel part of
the team. Of course, the down side to this is that there may be some unwelcome
interference from them, but that is the cost we have to pay.
Developing disaster scenarios is a good method of making
management aware of the ongoing risks and their consequences. Always include
this while justifying a security budget.
A good security program should strive to infuse a sense of
security into everyone in the organization. Everyone should be made aware of
security concepts, the threats and the pitfalls to avoid. This requires a
large training budget, which is usually not available. We have successfully
implemented an alternative to universal training at a large US company. We invented the role of a “Security Agent”. We selected one or two staff from each
group and trained them with security concepts. They were to watch over the
developments in their groups and report back to the security officer. They
were empowered to provide guidance to their groups on some security issues.
Their main value came from the advance notice that they provided whenever their
groups had a make a decision that may affect security. For example, say that
the HR department was dealing with a new benefits provider and that vendor quietly
installed a dial up connection to a host for “maintenance”. The HR managers
may not recognize the security impact of this connection. Hopefully, one of
the agents in the HR group would notice it and bring it up for review by the
security group. Organizationally, these “agents” reported to their functional
managers, but also had a matrixed relation to the security officer. The
security officer provided some input to their annual reviews.
We should insert a “Security Review” into most of the development
and purchasing processes. When an application is being developed, a security
review is justified at multiple stages before the deployment, depending on the
application. For example, we recommend separate reviews of the concept, the
architecture, the implementation plan, the code, the deployment plan and of the
training plan for administrators. When a new business application is being
purchased, then its architecture should be reviewed for its security and also
to see how it would integrate into the existing security infrastructure.
Keeping a Security Architecture current is an ongoing job. However, a good security program can be maintained with sufficient effort and with this methodology. The program has to be constantly revised and updated to keep up with new attacks and new products. We have explained the key steps involved. The implementers need to iterate through the process as often as feasible.