Page 2 of 2   « previous page

Application Security
Within an enterprise there are many applications used for data input or reporting, communications, database access and management, and Web services. Your actual matrix may be simple, or very complex, but each application should comply with your basic security architecture and business framework. It is important to provide the highest level of application security without impairing the business capability.

The Five Ws
Who, what, when, where, and why? These questions should have clear, documented, auditable answers before the installation of any application's software. Who is the application's primary user community? What is their business function? When do they require access to the application? Where is the application installed, and from where is it accessed? Why is the application important? How does it meet business needs? In addition, the answers should be periodically reviewed within the security architecture to make sure they remain relevant and adequately addressed throughout the life cycle of the application.

As each question is answered, security architecture issues will fall out. For example, a communications application is used by sales staff via remote access from anywhere in the world at any time. The access allows sales to enter orders, query inventory and/order status, query ERM application modules, and modify personal account information within specific sales parameters. Again, a visualization tool aides in this evaluation - consider Table 1.

You can see many communications and application security issues emerge from this simple case description. These issues may include remote access via VPN or IPSEC tunneling, http or https access, middleware application security, boundary testing, address checking, and security testing to ensure that credentialing to the queried applications is appropriate and at the level required to do business (but no higher).

Match each of the assets valued in your enterprise security plan against this simple set of questions and be prepared to address security concerns that emerge. Keep in mind that the goal is to enable business processing while safeguarding assets at the highest level possible. Often this is accomplished by providing the lowest level of access required for a specific business task as well as testing the application for security. You will decide if the protection is worth the risk of leaving your operations open, or at what level you can afford to provide protection.

External Access
Your company security architecture should also allow external access at the least privilege-required level. In the previous example, sales staff access may happen from anywhere in the world. Your security architecture should allow this access with a secure application, providing the highest level of security for accessing only the application(s) they require for their business function.

An example of this might be a company providing remote access to their development staff for a variety of services, including at-home development at all hours for principal programmers, file upload/download capability to outsourced marketing/public relations firms, or potential customers accessing the corporate Web site. In these scenarios, the "who, what, when, where, and why" may resolve to thousands of annual visitors accessing applications to get product, to pay for services, or to ask a general question. Access could occur from anywhere in the world, based on the specific application access.

The corresponding network security requirements to fit the business framework might include http and https access passed from public networks to the private corporate LAN or WAN, thus allowing middleware applications to query customer record databases and payment processing applications. These systems could be in separate data centers, requiring data transmission on the corporate network to pass from the internal Web/middleware systems to the database systems, to the financial systems, and return the requested information to the viewer while completing internal processing - all within stringent requirements for data security.

In a complex transaction model, having a security architecture and business framework provides guidelines and limits, helping to ensure that business is done efficiently while maintaining the highest level of security possible. It's no longer enough to determine that the data is secure in transmission. Denial of service attacks on the corporate Web server can be catastrophic when each second of real time represents hundreds or thousands of transactions. To keep this from happening, to detect it, or to analyze it, companies need to actively protect the business from these type of actions.

Physical Access
With today's phones, PDAs, handheld computers, and wireless laptops, the limits of physical access security have never faced stronger challenges, while the requirements continue to skyrocket. You should evaluate the kind of physical access required with the potential threat. For example, are your company's assets located in an area subject to natural or environmental threats, such as earthquakes, hurricanes, tornadoes or floods? Are your global resources in areas subject to terrorism or civil unrest? What about the likelihood of corporate data theft or destruction by disgruntled employees or ex-employees?

It is likely that your organization faces some of these risks. Does your staff walk away from systems with active logins, leave the server room door open, or leave keys in the server racks in machine rooms? The scope, detail, and expense of your physical access security plan should also be compared to the value of assets and secured to the highest degree possible without adversely affecting normal business functions. Installing screen locks that become active after 15 seconds of idle time may cause considerable productivity loss, as well as increase employee irritation. Requiring all documents to be shredded before disposal may only be required where vital data can be compromised.

The Sum of the Parts
Ongoing scrutiny, review, and modification of each of the areas presented provide a basic groundwork for security architecture. The key word is "ongoing" - security architecture is not a static process. You can't "set it and forget it." Implementing the maximum level of security required by each asset in your business is a task measured in man-years, not man-hours. But when compared to the value of your company's information systems, isn't it worth it?

Reference Section

• www.cisecurity.org/
• www.sans.org/score/
• www.itsecurity.com/dictionary/biba.htm
• http://e-government.cabinetoffice.gov.uk/ Resources/FrameworksAndPolicy/fs/en
• www.attackprevention.com/ap/library/securitymodels.htm
• www.crime-research.org/news/07.06.2004/320/
• www.itsecurity.com/dictionary/cw.htm

Page 2 of 2   « previous page