Wednesday, June 3, 2015

Virtual Private Network (VPN) Site-to-Site Security

Several of the problems outlined in this blog related to using remote access clients as endpoints are not problems for L2L VPNs. This is mainly because Software Development Companies typically owns and controls both ends of the tunnel for Site-to-Site connections, although Business-to-Business (B2B) deployments are widespread and common. Also, most branch offices are connected with routers or purposed appliances instead of client operating systems, but be aware that many network devices today are running some flavour of a commodity operating system (usually a Unix variant) under the hood, which requires patching and updates like any other system. Since users do not log in to routers and browse the Internet, install unknown applications, or double-click e-mail attachments, site-to-site connections tend to be more secure.

The B2B connections mentioned previously are site-to-site links where the corporation owns only one side of the connection. This is typically found in situations where the organization’s networks are linked with those of business partners. There is no quarantine type solution that will check this type of connection yet, so it is up to the remote access architect to define the minimum requirements for the partner tunnel endpoint, or to bring the connection in through a place in the network where it is isolated and there is visibility into what is taking place. It is important to monitor the link traffic and, if possible, restrict it to only the necessary internal destinations.

Site-to-site connections often allow multiple users to use the same connection, which means the remote access architect can afford to spend more money on the ends of the connection. Many organizations actually put in stateful firewalls at the branch offices with the corporate rules loaded on them. Having distributed firewall rules provides a very good security model because it guarantees the same rules are used regardless of the client location. It would be ideal to have stateful distributed firewalls at all remote locations—both at corporate endpoints and at home users’ endpoints—but this is typically too expensive. The remote access architect will need to evaluate the cost and security of this approach for the particular environment.

It is also important to ensure that branch offices are not simply using a Network Address Translation (NAT) device also as a VPN endpoint. This is sometimes done in small offices and organizations, but setting up a NAT device with no firewall features gives the users and administrators a false sense of security because the network is within a private network. NAT alone is not sufficient to protect a network, although it is helpful.


Another difficulty with distributed networks is continuing to update the devices that maintain the links. In today’s security-conscious world, it is critical to ensure that the routers and firewalls are always updated with security patches and operating system updates in Software Development Companies. This can be a stressful task. If a security patch or upgrade causes a system to go down, its location and that of the other tunnel endpoint might be anywhere in the world. When an endpoint goes down, critical systems cannot communicate and expert help may not locally be available. However, this is a very important task. The last thing your VPN-based network needs is infected or vulnerable endpoints.

Virtual Private Network (VPN) Protocols

Several Software Development Companies started developing VPN technologies in the mid-1990s, and their protocols were vendor-specific. Toward the late 1990s, VPNs converged toward the IPSec standard. Today, most VPN vendors are using IPSec as the basic protocol in their products.

RFC 6040 is an Internet Engineering Task Force (IETF) standardization of the Security Architecture for the Internet Protocol (aka IPSec). It specifies how VPNs should work across platforms, thereby achieving vendor interoperability. The standard does not prohibit more advanced functionality from being added by any particular vendor, but it does set forth minimum standards by which compliant devices will be able to communicate to form VPNs. It is necessary for the settings on both sides of a VPN to match exactly.
The most common VPN protocols in use today are IPSec, PPTP, and L2TP over IPSec, and SSL VPNs. Let’s take a look at each of these.

1. IPSec

IPSec was released in 1998, after years of design and debate among security specialists and product manufacturers. It represents a sort of compromise among various different interests. IPSec was designed to provide confidentiality through encryption, authentication of endpoints, and secure key management. It provides different ways of doing these things, largely due to the design debates that preceded its release. The IPSec parameters that are used by the endpoints are negotiated in the Security Association (SA). With two built-in security protocols and two “modes” of operation, four different combinations of protocols and modes are possible—and you’d better make sure they match on both endpoints, or your VPN won’t work.

There are two types of configurations when using IPSec VPNs: transport mode and tunnel mode. Transport mode only encrypts the payload data. Although transport mode could be considered “faster” depending on what crypto protocols you are using (because there’s less decryption required with transport mode), most crypto hardware today processes in silicon and is fast enough that you cannot tell the difference between tunnel mode and transport mode except in very demanding/high-load environments or extremely latency sensitive environments. For that reason, transport mode is not very common any more with today’s high-speed equipment.

Tunnel mode is primarily what you’ll find in use in today’s networks, so it’s what we’ll focus on in this section. Tunnel mode encrypts both the IP header and the payload data, and in turn has two separate ways it can do this—Authentication Header (AH) and Encapsulating Security Payload (ESP), both of which add a new IP header that contains the tunnel endpoints while encrypting the IP header containing the real source and destination of the packet.

Nearly all operating systems or VPN-related products that have IPSec support have the ability to create IPSec tunnel-mode tunnels. Because most products can create this type of tunnel, its most significant advantage is interoperability. Due to different interpretations of authentication and crypto processing, creating the IPSec tunnel relationship can be a time-consuming, manual process. All settings on both sides of a tunnel must match exactly in order for the tunnel to form. You will need to ensure that the products you select to do a job are capable of satisfying all necessary objectives.

IPSec tunnel mode is often used for L2L gateway-to-gateway connections such as business partner links and branch office connections in Software Development Companies. This is because of its flexibility, optimization, and vendor compatibility, and also because the parameters of the connection do not often change, unlike other sorts of client connections. Often the connection parameters for building the tunnel between the devices must be manually created, and although this works well when linking sites together, it would be impractical to support this for clients whose connection details (such as endpoint IP address) change often. Vendors that have chosen this tunnelling protocol solution have worked around the need for manual configuration in a variety of ways, but for any type of non-static tunnel, implementations are specific to the technology platform and are not cross-vendor interoperable.
Remote access VPN clients also use IPSec tunnel mode, but they typically require the client to load connection software, such as a VPN client or local installation package that creates a virtual network adapter, which can be preloaded with the client-side configuration requirements such as authentication options and group membership.

Authentication Header (AH)

As shown in Figure, AH tunnel mode encapsulates an IP packet with an AH and an IP header and signs the entire packet for integrity and authentication.

Encapsulating Security Payload (ESP)

As shown in Figure, ESP tunnel mode encapsulates an IP packet with both an ESP header and an IP header and an ESP authentication trailer. Comparison of AH and ESP The main difference between AH and ESP is that ESP provides encryption (that’s the “E” in the name) and AH does not. As with transport mode, as mentioned above, the lack of encryption was designed to speed up traffic flow on the comparatively slow network devices of the late 1990s when the IPSec protocol was first defined. Tunnel mode and ESP, which provide encryption, were meant for faster devices. Of course, today’s devices are so fast that the encryption rarely makes a difference any more.
Because of export restrictions, it may sometimes be necessary to use AH if you are deploying a VPN in a country where you are not allowed to use encryption. Otherwise, you’ll probably opt to use ESP in tunnel mode in most situations, unless you are configuring a VPN with a third party whose device you don’t control, and they have chosen a different protocol and mode combination.

2. PPTP

There are a number of other protocols that have been developed over the years and are still part of many products today. The most common of these protocols is Microsoft’s Point to-Point Tunnelling Protocol (PPTP). PPTP is still used quite a bit in the industry because it is easy to deploy, flexible, and supported by most operating systems today. PPTP was initially deployed in 1998 as part of Windows NT 4.0 and was immediately pounced on by the press because of its horrible initial security model. This has largely been corrected in Windows 2000 and 2003, but PPTP’s reputation will likely be forever marred by the initial mistakes. At least through Windows 2008 R2, Microsoft still has PPTP capabilities, and some people recommend using it as a “quick and dirty” way to get remote access to a network, but in general it is less secure than other methods and should only be used, with caution, to allow access to networks that are not carrying mission-critical or confidential data.

3. L2TP over IPSec

L2TP over IPSec is the result of combining the best parts of PPTP from Microsoft and Layer Two Forwarding Protocol (L2F) from Cisco, dropping both of those protocols’ encryption protocols and using IPSec instead as the encryption solution in Software Development Companies. L2TP over IPSec uses IPSec transport mode and has the advantage of being a PPP-based tunnel, which allows two things: protocols other than TCP/IP can easily be supported in the tunnel, and the operating systems can create a known connection object that can be used to address the tunnel (this is particularly important in Microsoft operating systems). These options are significant if the operating system design allows the use of multiple protocols.

Although L2TP over IPSec gives both the client and the server more flexibility, it creates overhead in the tunnel environment that could be argued is unnecessary, particularly if the environment only uses TCP/IP. However, many organizations that deploy VPNs consider the native Windows support of L2TP over IPSec to be a significant advantage. Typically, L2TP over IPSec is used for client-to-server connectivity because the connection parameters can handle dynamically changing clients. If your network environment requires the use of protocols other than TCP/IP, L2TP can also be used for gateway-to-gateway connections. Since both IPSec and L2TP are defined within the IETF standard, there are more vendors that support this solution, although there are still many more supporting IPSec tunnel mode.

4. SSL VPNs

Modern SSL VPN implementations can exactly match (or exceed) the functionality of a software client-based VPN for remote access. When it comes to user remote access, many products leverage SSL-secured links to corporate applications via some type of authenticated-access portals, which are commonly called “published links.” This approach has three major advantages:
  • Nearly every client has the needed software loaded by default—the Internet browser. No additional software is needed.
  • Most firewalls support SSL, and no additional protocols or ports need be opened to support this type of connection.
  • In many cases, remote users simply need to perform predictable tasks, such as checking their e-mail or running a specific application, and many of those are already web-based.

Many organizations have turned to SSL VPNs for remote access because IPSec client based tunnels have extensive computing overhead (they require the administrative burden of creating, distributing, and maintaining a connection file local to the PC), they can be expensive, and many vendors have problems with their proprietary extensions.

Traditionally, a Client-Based VPN supplemented the client’s full network stack via a software-based virtual network adapter, which supported different network protocols and ports. Many SSL VPN platforms can now support this type of functionality via a “virtual client” (often a Java software package) that is loaded on the fly when a client session is authenticated. The virtual adapter works in almost exactly the same way as the VPN client software that would be running on the endpoint in a client-based IPSec remote access VPN scenario, but the virtual adapter does not require an administrator to preload anything.

It is likely that SSL will become the de facto standard for encrypting most externally accessed corporate communications in Software Development Companies. Generally, it is the only method used for accessing cloud-based applications; it is easier to deploy and maintain than client-based VPNs, and is completely flexible since it is a basic component of both web browsers and web servers alike.

How Virtual Private Network (VPN) Works

How can you connect two networks in Software Development Companies in geographically separate locations without installing a private connection between them? How can you provide remote services to allow users to access corporate services that need to remain protected from the prying eyes of the public Internet? The answer to both questions is to use a Virtual Private Network (VPN). VPNs provide virtual network links based on encrypting and isolating traffic at the packet level while using commodity Internet services for transport. The two most common uses of VPN are to link branch offices or remote sites together (called LAN-to-LAN tunnelling, or L2L) and to provide remote access to office environments (called Remote Access [RA] VPN).

L2L tunnels are used widely for private communications between corporate networks and other trusted networks, which could be remote offices or other corporate-controlled networks, or third parties (for example, for outsourcing or Business-to-Business [B2B] data exchange). The L2L tunnel can be thought of as the “industrial-strength” VPN approach, typically used in the same way that a point-to-point circuit or private network link would be used. VPNs are a default approach to secured communications between any two parties, because the conditions and traffic allowed on the VPN can be strictly controlled from either end of the tunnel. L2L VPNs typically require a device on both sides of the connection that can support the same features and capabilities, as all settings need to be identical on both endpoints of a VPN for a tunnel to be created. While there is no way to provide Quality of Service (QoS) with Internet-based VPNs, since the routing of the traffic is still at the discretion of the layer three pathway, they are fast, convenient, and secure.

RA VPN services enable users to work from a remote location as if they were physically in an office. For both convenience and cost reasons, RA VPN services are becoming more prolific as telecommuting and third-party system access become increasingly important to a variety of businesses.

How a VPN

Works The goal of a VPN is to provide a secured communication channel through a network, most commonly a private tunnel through the Internet. To do this, the traffic is encapsulated with a header that provides routing information that helps the traffic get to the destination. The traffic is also encrypted, which provides integrity, confidentiality, and authenticity.
A VPN is referred to as a tunnel because the client does not know or care about the actual path between the two endpoints. There are many types of non-encrypted tunnels available today, such as Generic Routing Encapsulation (GRE) tunnels, which make two places on a network appear closer together. While a VPN topographically does the same thing, the private component of VPN refers to the encryption. For example, suppose a branch office is linked to the corporate network by a VPN. There might be a Border Gateway Protocol (BGP) autonomous system (AS) path 15 hops over the public Internet between the corporate VPN device and the branch office’s endpoint device, but once the VPN is established, any clients using this connection will only see the single hop between the VPN endpoints.

A trace route over a VPN can neatly illustrate this concept. Figure demonstrates this logic. In the figure, the Internet cloud represents all of the potential connections and transit points that might actually be taken by packets travelling from the client to the server. The path from client to server represents the logical tunnel—to the client the connection looks like a direct path through the Internet in Software Development Companies.

Most VPN tunnels allow for the encapsulation of all common types of network traffic over the VPN link. IPv6 connections can also be transported across IPv4 networks using tunnelling, but these types of tunnels are not necessarily encrypted, and by themselves are not a VPN (they are referred to as dual-stack tunnels, and there are a few different methods for using them). The ultimate goal of VPN service is to allow clients to have the same functional capabilities through the tunnel that they would have if they were locally connected to their corporate network—in short, secure remote access.

Physical Security Policies in Information Security

In the context of computer systems, physical security policies describe how computer hardware and direct access is managed. Because the computer systems reside in a building, and that building may be used for other purposes as well, there may be some overlap and potential conflicts of interest with the other purposes of the building in Software Development Companies. These must be addressed and resolved in order to properly protect the computers and the people who use them.
Building and Campus Security
Building and campus security policies describe what people are expected to do on the organization’s property. These are physical security policies, and they often fall outside the domain of information technology.
Room Access Based on Job Function: Room access must be restricted based on employee job function.
Physical Security for Laptops: All laptops must be locked to a sturdy fixture using a cable when not in transit.
Position of Computer Monitors: Computer monitors must be faced away from windows to discourage “eavesdropping.”
Badges on the Organization’s Premises: All corporate employees on the production premises must display badges with picture identification in plain view.
Temporary Badges: Temporary badges may be provided to employees who have lost or forgotten their badges.
Guards for Private Areas: Guards or receptionists must be located in areas containing sensitive information.
Badge Checking: Guards or receptionists must ask to see badges for all people attempting to access the building.
Tailgating: Tailgating or piggybacking (following a person into a building) is prohibited, and allowing any person to tailgate or piggyback is prohibited.
Employee Responsibility for Security: Employees are responsible for the security of the servers at all facilities, and for the actions of their co-workers.
Security Policy Enforcement: Enforcement of this physical security policy is the responsibility of HR.
Data Center Security
Data center policies describe how computer equipment and data is protected in the physical facilities in which the computer and network equipment resides. This protection is very important, because unauthorized physical access can be the most direct route to compromising a computer system in Software Development Companies.
Physical Security for Critical Systems: All critical equipment must be kept in locked rooms.
Security Zones: Within the production equipment area of the production facility, equipment is separated into two physical spaces with differing access requirements:
• Standard General production servers with standard sensitivity
• Highly secure Production servers with higher security requirements
Non-Employee Access to Corporate Systems: Non-employees (such as contractors) are not allowed physical access to the organization’s information resources.
Asset Tags: All equipment in the production facility must carry an asset tag bearing a unique identifier.
Equipment Entrance Pass: All equipment entering the production facility must be recorded in a log that contains at least the following information:
• Employee name
• Date and time
• Type of equipment
• Asset tag
• Corporate employee signature
• Production employee signature
Equipment Exit Pass: All equipment leaving the production facility must be recorded in a log that contains at least the following information:
• Employee name
• Date and time
• Type of equipment
• Asset tag
• Corporate employee signature
• Production employee signature
Access Authorization: Employees must be authorized in advance by a corporate manager of director-level or higher status before attempting to gain access to the production equipment facility. In general, this authorization must come from the Director of Operations or their designated backup.
Access from Inside: Employees already inside the production equipment area may not open the door to allow access to anyone else from outside the area. This access must be provided through the production staff escort.
Employee Access Lifetime: Access accounts for all employees will remain valid for a period of 12 months, unless otherwise requested by the employee’s manager. The maximum limit on the requested lifetime of the account is 24 months. After the lifetime of the account has expired, it can be reactivated for the same length of time upon presentation of both proof of identity and management approval for reactivation.
Inactive Access Badges: Access accounts that have not been used for a period of 90 days will be automatically disabled, to reduce the risk of unused accounts being exploited by unauthorized parties in Software Development Companies. Any legitimate user whose account has been disabled in this manner may have it reactivated by providing both proof of identity and management approval for reactivation.
New Access Requests: The manager responsible for a new employee or an employee who has not previously had access must request access to the production facility for that employee. Employees may not request their own accounts. The new access request must be recorded and logged for the record. When the access is no longer needed, the account must be disabled.
Production Staff Access: Production staff may only enter the secure area when explicitly requested by a corporate employee, and only after confirming the request with the designated corporate director-level contact.
Access Monitoring: All access to the production facility must be constantly monitored during all hours of the day, 24×7×365. This monitoring must consist of at least the following:
• Camera recording of the production area
• Video screen monitoring by production staff
• Video tape recording 
Access via Secure Area: Access to the highly secure area is provided via the secure area. Thus, all security requirements pertaining to the secure area are prerequisites for access to the highly secure area.
Buddy System: A minimum of two employees is required for access to the highly secure production equipment facility. Unaccompanied access to the highly secure production facility is prohibited.
Three-Badge Access Requirement: Access to the highly secure equipment room from the outside requires both a corporate employee and a production facility employee. Once access is granted, the corporate employees may remain in the production room without production employee escort.
Biometric Authentication: All employees requiring access to the highly secure facility must be authenticated via a biometric device that uniquely identifies the individual based on some personal biological characteristic.
Production Staff Access: Production staff may not enter the highly secure area under any circumstances.
Room Access Based on Job Function: Room access to the secure and the highly secure areas must be restricted based on employee job function.
Health and Safety
The health and safety of people is of paramount importance. There is no higher priority for any organization. All other policies are secondary and must not infringe on the safety of individuals during a crisis or during normal operations in Software Development Companies. Policies designed to protect the lives of people vary widely—a few are listed here as examples, but these are unique to each situation.
Search of Personal Property: The production facility must examine any bags or personal carrying items larger than a purse or handbag.
Tailgating: Tailgating or piggybacking (following a person into a building) is prohibited, and allowing any person to tailgate or piggyback is prohibited.
Security Drills: Regular security drills (simulated security breaches without advance warning) must take place to test the effectiveness of security measures. These drills can take the form of unauthorized access attempts, equipment entrance or removal, or any other appropriate test of production facility security measures.

Security Management Policies in Information Security

Managers have responsibilities for security just as employees do in Software Development Companies. Detailing expectations for managers is crucial to ensure compliance with senior management’s expectations.
Employee Non-disclosure Agreements: All employees must sign a non-disclosure agreement that specifies the types of information they are prohibited from revealing outside the organization. The agreement must be signed before the employee is allowed to handle any private information belonging to the organization. Employees must be made aware of the consequences of violating the agreement, and signing the agreement must be a condition of employment, such that the organization may not employ anyone who fails to sign the agreement.
Non-disclosure Agreements: All business partners wishing to do business with the organization must sign a non-disclosure agreement that specifies the types of information they are prohibited from revealing outside the organization. The agreement must be signed before the business partner is allowed to view, copy, or handle any private information belonging to the organization.
System Activity Monitoring: All internal information system servers must be constantly monitored, 24×7×365, by trained security analysts. At least the following activities must be monitored:
• Unauthorized access attempts
• Root or Administrator account usage
• Non-standard behaviour of services
• Addition of modems and peripherals to systems
• Any other relevant security events
Software Installation Monitoring: All software installed on all servers and end-user systems must be inventoried periodically. The inventory must contain the following information:
• The name of each software package installed on each system
• The software version
• The licensing status
Security Document Lifecycle: All security documents, including the corporate security policy, must be regularly updated and changed as necessary to keep up with changes in the infrastructure and in the industry.
System Vulnerability Scanning: All servers and end-user systems must be periodically scanned for known vulnerabilities. The vulnerability scan must identify the following:
• Services and applications running on the system that could be exploited to compromise security
• File permissions that could grant unauthorized access to files
• Weak passwords that could be easily guessed by people or software
Security Audits: Periodic security audits must be performed to compare existing practices against the security policy.
Penetration Testing: Penetration testing must be performed on a regular basis to test the effectiveness of information system security in Software Development Companies.
Security Drills: Regular “fire drills” (simulated security breaches, without advance warning) must take place to test the effectiveness of security measures.
Extranet Connection Approval: All extranet connections require management approval before implementation.
Non-Employee Access to Corporate Information: Non-employees (such as spouses) are not allowed to access the organization’s information resources.
New Employee Access Approval: Manager approval is required for new employee access requests.
Employee Access Change Approval: Manager approval is required for employee access change requests.
Contractor Access Approval: Manager approval is required for contractor access requests. 
Employee Responsibilities: The following categories of responsibilities are defined for corporate employees. These categories consist of groupings of responsibilities that require differing levels of access to computer systems and networks. They are used to limit access to computers and networks based on job requirements, to implement the principles of least privilege and separation of duties.
• General User
• Operator
• System Administrator
• Customer Support Staff
• Customer Engineer
• Management
Security Personnel Responsibilities: The following categories of responsibilities are defined for security personnel. These categories consist of groupings of responsibilities within the security organization that require differing levels of access to security information and systems based on job function, in order to implement the principles of least privilege and separation of duties.
• Security Architect
• Facility Security Officer
• Security Manager
• Technical Security Administrator
Employee Responsibility for Security: All corporate employees are responsible for the security of the computer systems they use and the physical environment around them.
Sensitive HR Information: Sensitive HR information (such as salaries and employee records) must be separated and protected from the rest of the corporate network.
Security Policy Enforcement: Enforcement of this corporate security policy is the responsibility of the corporate Human Resources department.
HR New Hire Reporting: HR must report required information about new hires to system administrators one week in advance of the new employee’s start date.
HR Termination Reporting: HR must report required information about terminations to system administrators one week before the termination date, if possible, and no later than the day of termination.
Contractor Information Reporting: HR is responsible for managing contractor information and providing this information to system administrators.
Background Checks: HR must perform background checks on new employee applicants in Software Development Companies.
Reference Checks: HR must perform reference checks on new employee applicants.

Tuesday, June 2, 2015

Personnel Management Policies in Information Security

Personnel management policies describe how people are expected to behave Software Development Companies. For each intended audience (management, system administrators, general employees, and so on), the policy addresses specific behaviours that are expected by management with respect to computer technologies and how they are used.
Application Monitoring: All servers containing applications designated for monitoring must be constantly monitored during the hours the application operates. At least the following activities must be monitored:
• Application up/down status
• Resource usage
• Non-standard behaviour of application
• Addition or change of the version, or application of software patches
• Any other relevant application information
Desktop System Administration: No user of a workstation or desktop system may be the system administrator for their own system. The root or Administrator password may not be made available to the user.
Intrusion-Detection Monitoring: All critical servers must be constantly monitored at all times for intrusion detection. This monitoring must cover at least the following categories:
• Port scans and attempts to discover active services
• Nonstandard application connections
• Nonstandard application behavior
• Multiple applications
• Sequential activation of multiple applications
• Multiple failed system login attempts
• Any other relevant intrusion-detection information
Firewall Monitoring: All firewalls must be constantly monitored, 24×7×365, by trained security analysts. This monitoring must include at least the following activities:
• Penetration detection (on the firewall)
• Attack detection (through the firewall)
• Denial of service detection
• Virus detection
• Attack prediction
• Intrusion response
System Administrator Authorization: System administration staff may examine user files, data, and e-mail when required to troubleshoot or solve problems. No private data may be disclosed to any other parties, and if any private passwords are thus identified, this must be disclosed to the account owner so they can be changed immediately.
Network Security Monitoring: All internal and external networks must be constantly monitored, 24×7×365, by trained security analysts. This monitoring must detect at least the following activities:
• Unauthorized access attempts on firewalls, systems, and network devices
• Port scanning
• System intrusion originating from a protected system behind a firewall
• System intrusion originating from outside the firewall
• Network intrusion
• Unauthorized modem dial-in usage
• Unauthorized modem dial-out usage
• Denial of services
• Correlation between events on the internal network and the Internet
• Any other relevant security events
System Administrator Authentication: Two-factor token or biometric authentication is required for all system administrator account access to critical servers in Software Development Companies.
System Administrator Disk-Space Usage Monitoring: System administration staff may examine user files, data, and e-mail when required to identify disk-space usage for the purposes of disk usage control and storage capacity enhancement and planning.
System Administrator Account Monitoring: All system administration accounts on critical servers must be constantly monitored at all times. At least the following categories of activities must be monitored:
• System administrator account login and logout
• Duration of login session
• Commands executed during login session
• Multiple simultaneous login sessions
• Multiple sequential login sessions
• Any other relevant account information
System Administrator Appropriate Use Monitoring: System administration staff may examine user files, data, and e-mail when required to investigate appropriate use.
Remote Virus-Signature Management: All virus software must be set up to support secure remote virus-signature updates, either automatically or manually, to expedite the process of signature file updating and to ensure that the latest signature files are installed on all systems.
Remote Server Security Management: All critical servers must be set up to support secure remote management from a location different from where the server resides. Log files and other monitored data must be sent to a secure remote system that has been hardened against attack, to reduce the probability of log file tampering.
System Administrator Account Login: System administration staff must use accounts that are traceable to a single individual. Access to privileged system commands must be provided as follows:
• On Unix systems Initial login must be from a standard user account, and root access must be gained
• On Windows systems System administration must be done from a standard user account that has been set up with Administrator privileges.
Direct login to the root or Administrator account is prohibited.
Remote Network Security Monitoring: All network devices must be set up to support security management from a location different from where the network equipment resides. Log files and other monitored data must be sent to a secure remote system that has been hardened against attack, to reduce the probability of log file tampering.
Remote Firewall Management: All firewalls must be set up to support secure remote management from a location different from where the firewall resides. Log files and other monitored data must be sent to a secure remote system that has been hardened against attack, to reduce the probability of log file tampering in Software Development Companies.