Security

• Data integrity checks and data encryption: Stored before and compared after critical data transmission, integrity checks can include encrypted totals, which can identify data transmission errors. Network transmissions using encrypted totals need to use the same encryption at each end of the transmission, either via the network or via the application after delivery. Using different encryption methods for different types of transmissions or different data streams makes data transmission even more secure. SSH, SSL, and Secure Telnet are examples of network applications that encrypt their data in transmission. If you have multiple locations (i.e., R&D in one office, finance in another), data transmission between the offices should be encrypted and the contents verifiable.
• Transmission logging: Storing an audit trail for transmissions or applications that transmit data can include the transmission date, time, transmission type, source, and destination.
• Transmission loss: In some cases, data loss on an otherwise reliable network can indicate port-scanning activity (i.e., someone viewing transmission samples looking for vulnerabilities). With 65,535 TCP ports on a system (using TCP/IP as the lion's share of network traffic), active data transmission to well-known ports such as http (port 80) or telnet (port 23) are the tip of the iceberg, but are often the first point of attack. To defend against this activity, keep port-scanning tools off of the network with a published mandate in security policies known to all employees, backed up by a periodic review of hardware and software inventory on computers. Keeping unused ports closed and current network patches on systems also enhances network security.
• Change control review: While many system and network administrators view change control as an impediment, reviewing network devices or software before they are introduced allows a larger perspective, including the security and business framework. The extra time spent here is inexpensive insurance over the system's life cycle. This is particularly true when your company is starting up operations. Documenting and following best practices produces repeatable, reliable results.

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.