630-3 Yhtomit

INTRODUCTION TO PART V

DETECTING SECURITY BREACHES

No matter how well we implement security mechanisms, we are facing human oppo- nents who may counter our best efforts until we can respond appropriately. How do security and network administrators find out if there has been a breach of security? How can they evaluate their own defenses before they are penetrated? This part includes chapters on:

52. Application Controls. Application-software security and logging 53. Monitoring and Control Systems. System logging and data reduction methods 54. Security Audits. Measuring compliance with explicit policies and with industry

standards

55. Cyberinvestigation. Organizing effective digital forensic studies of observed or suspected security breaches, for internal use, and for cooperation with law enforcement

V · 1 Bosworth, S., Kabay, M. E., & Whyne, E. (Eds.). (2014). Computer security handbook, set. Retrieved from http://ebookcentral.proquest.com Created from apus on 2018-03-19 16:25:53.

C o p yr

ig h t ©

2 0 1 4 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

Bosworth, S., Kabay, M. E., & Whyne, E. (Eds.). (2014). Computer security handbook, set. Retrieved from http://ebookcentral.proquest.com Created from apus on 2018-03-19 16:25:53.

C o p yr

ig h t ©

2 0 1 4 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

52CHAPTER

APPLICATION CONTROLS

Myles Walsh and Susan Baumes

52.1 INTRODUCTION 52 · 1

52.2 SYSTEMS ARCHITECTURE AND DESIGN 52 · 2

52.3 INPUT AND ENTITLEMENTS 52 · 2 52.3.1 Input 52·3 52.3.2 User Entitlements 52·4

52.4 DATABASES AND UNDERLYING DATA CONTROLS 52 · 5 52.4.1 Data Corruption 52·6 52.4.2 Database Management

Subsystems 52·7

52.4.3 Distributed Databases 52·8 52.4.4 Recovery and Restart 52·12

52.5 BATCH FILES 52 · 13 52.5.1 Backup File

Creation 52·13 52.5.2 Audit Controls 52·13

52.6 DATA INTEGRITY AND VALIDATION 52 · 13 52.6.1 Validation Controls 52·13

52.7 CONCLUDING REMARKS 52 · 16

52.8 FURTHER READING 52 · 16

52.1 INTRODUCTION. Application controls can be broad and multifaceted. Given the complexity of many applications, no single system can provide all of the controls needed. As part of the design of a new or changes to an existing application, there are a number of controls that must be considered to ensure that the underlying data is protected against threats to the six fundamental attributes of information (confiden- tiality, control, integrity, authenticity, availability, and utility) as discussed in Chapter 3 in this Handbook. As with all other information security areas, a defense-in-depth strategy for application controls is a necessity. As an example, should a Web server be publically available? If not, then that control would have to be considered in the design of the application.

The basis of application controls fall into three areas:

1. Systems architecture and design 2. User input and entitlements 3. Database and underlying data controls

There is tremendous complexity in modern systems due to architecture changes and cost pressure on IT departments. Because of this complexity, there is the potential to have so many controls that they end up overriding one another and in some cases

52 · 1 Bosworth, S., Kabay, M. E., & Whyne, E. (Eds.). (2014). Computer security handbook, set. Retrieved from http://ebookcentral.proquest.com Created from apus on 2018-03-19 16:25:53.

C o p yr

ig h t ©

2 0 1 4 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

52 · 2 APPLICATION CONTROLS

limiting their usefulness. It is easiest to design a net new application and consider all of the controls necessary, but the same due diligence is required for changes to existing applications whether new functionality is being added or there are changes to business processes that may require large entitlement changes. All changes in applications need to follow a strict design method whether using agile, waterfall, or some other methodology.

It should be noted that every architecture tier plays a role in applications and each tier must have some controls in place.

Although this chapter focuses on data-processing applications, similar issues arise in supervisory control and data acquisition (SCADA) systems for real-time process control.

52.2 SYSTEMS ARCHITECTURE AND DESIGN. Architecture and design pro- vides the first line of defense for applications. The configuration of the design and systems are paramount. Protection of and how the controls effect an application must be considered in the underlying architecture and design.

Architecture controls fall into a number of categories, but they encompass all of the tiers of a system supporting an application. These are standard best practices for systems.

Things to consider when designing system controls for applications include:

1. What underlying processes need to run on the system in support of the applica- tion? Recommendation: Limit processes to only those that are required.

2. What ports need to be open in order for the system to run correctly in support of the application? Recommendation: Limit ports to only those that are required. See Chapter 26 in this Handbook for further discussion of gateway security.

3. Who has direct access to the system and why? Recommendations: Practice least privilege and require special approval for higher risk or administrative access. Regularly review all access, but if access is higher risk, more frequent review and validation of access may be required.

4. What controls and processes will be in place for support of the application? Similarly, what controls will be in place for change control or patching? Recommendations: Define, follow, and validate change control processes for the systems and applications that those systems require. See Chapter 40 in this Handbook for more details of patch management.

5. How are the interacting systems validated with each other to ensure they are who they say they are? Recommendations: Digital certificates and two-way SSL can be used to ensure the validity of the underlying systems. Know and understand what systems can communicate with other systems and why.

52.3 INPUT AND ENTITLEMENTS. From an application development perspec- tive, the biggest control that must be considered is user input. User input falls into two distinct areas. What rights or entitlements does or should the user have and what are the limits for the input that the user is allowed to have? Business requirements of the applications generally drive these specifications. An example could be the input field of an address. The business may stipulate that the field be 50 characters and that only certain types of users be granted access to input, change, or delete the field.

Bosworth, S., Kabay, M. E., & Whyne, E. (Eds.). (2014). Computer security handbook, set. Retrieved from http://ebookcentral.proquest.com Created from apus on 2018-03-19 16:25:53.

C o p yr

ig h t ©

2 0 1 4 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

INPUT AND ENTITLEMENTS 52 · 3

Questions to ask regarding entitlements include:

� What is a user or groups of users allowed to do in the application? � What should the user be able to view, create, update, or delete? � Are there specific functionalities that a particular user or groups of user are not allowed to perform because of their current role within an organization?

� From a reporting perspective, the same questions need to be asked.

As part of application design all of those questions need to be answered based on the business requirements.

On the other hand, each input field within those entitlements must be defined within certain limits and those limits must be carried from the initial input to the underlying data structure. Both the application and the underlying database can control the limits and data entered.

Continuing with the above example, the 50-character address field should only accept 50 characters. The field length should be 50 and there must be input validation completed to ensure only valid or approved characters are entered. This control can be based both at the field level of the application as well as the database where the data will be stored. Limiting the length of inputs is a key defense against injection attacks and buffer overflows.

Typically, data validation has occurred closer to user input simply due to speed of networks, and more recently, real-time user validation provides a better experience for the user (e.g., validation as the field is being entered versus at the “submit” button of a Web-based form). Best practice requires server-based validation of input prior to processing. Initial checks can be completed on a Web form or field within a desktop application, but server-side validation is better since it is closer to internal systems.

Systems can accept input from both users and systems; for example, a batch process may take input from one source, manipulate it, and carry it to another source. Input, whether by a user or system, must be validated.

Database controls work in support of application controls. If, for example, field-level validation were not occurring in an application, the underlying database could be used to protect against bad data. As with the example above, if the field-level validation and the server-side validation failed, the database field can be defined as a 50-character field. Most database systems will truncate and ignore additional data that is entered into a field.

52.3.1 Input. As stated above, all input must be cleansed and validated to ensure that only acceptable values are received and processed. This is true for user input as well as systems input. The same thought must be used for a database perspective. Obviously, there are challenges with this method. If all 50-character fields for addresses must be updated to accept 60, multiple changes and more thorough testing are required.

Organizations may decide that the applications data is not critical and design it with looser controls. This can lead to issues simply because an attacker may use an application with fewer controls as a jumping point to get to an application with more sensitive data.

One cannot stress enough the importance of data validation for all user input. Many attacks on systems could have been prevented if proper and comprehensive data validation were completed (e.g., many cross-site scripting (XSS) and cross-site request forgery (XSRF) attacks [see Chapter 16 in this Handbook] can be prevented

Bosworth, S., Kabay, M. E., & Whyne, E. (Eds.). (2014). Computer security handbook, set. Retrieved from http://ebookcentral.proquest.com Created from apus on 2018-03-19 16:25:53.

C o p yr

ig h t ©

2 0 1 4 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

52 · 4 APPLICATION CONTROLS

with validation). Not accepting certain known malicious characters, encoding certain characters, blocking certain string combinations, and understanding application attack vectors are important to keep applications secure and maintain integrity. Application designers need to work with their business partners and explain the issues with allowing certain types and sequences of characters.

As with all information security controls, multiple levels of control are needed. It is not appropriate to build an application where there is only field-level validation of input. Multiple controls need to be used in order to provide a defense-in-depth strategy for applications.

52.3.2 User Entitlements. Especially daunting are user entitlements for appli- cations. Defining and limiting access while enabling users to complete their required tasks can be a formidable challenge. Application controls are paramount when consid- ering what a user can do when within an application. Entitlements are also important when considering segregation of duties within the same application, as users change roles within an organization, or even what, if any, access a developer would have to a production environment.

User access rights are the entitlements granted to users or groups to perform functions within an application. As an example, a user that is supposed to have read only access to data should not be granted rights to an account that allows updates. Good design uses systems, application, and database controls to allow or restrict users to perform different functions.

If an individual’s role within an organization is as a developer, should they be allowed to migrate code to production? Best practices tell us that they should not; however, every organization is different and development teams may also migrate code to production. The important thing is to:

1. Understand where entitlements are granted, to whom, and why. 2. Verify entitlements on a cyclical basis. 3. From a development perspective, have entitlements listed as requirements, in the

test plan, and validate that the tests were successful.

52.3.2.1 Practice Least Privilege. As a best practice, apply least privilege to user entitlements, as it should be applied in all other areas of technology in order to maintain control over data and processes. How the underlying system is architected, the size of the organization, and regulatory controls will dictate the feasibility of achieving the best-practice state.

In many instances, business requirements do not consider which specific types of users should have access to which functionality. This lack is not sustainable, sim- ply because applications are constantly changing, functionality being added, legacy architecture being updated, and new technologies being included.

Careful consideration must be given to grant users only the permissions required to do their job function(s) and controls. Comprehensive testing must also be conducted to ensure access creep does not occur as changes are made to the application.

52.3.2.2 Solving the Problem. For smaller applications, one can easily define the different business requirements with the functions that should have access. A simple matrix may do, for example:

Bosworth, S., Kabay, M. E., & Whyne, E. (Eds.). (2014). Computer security handbook, set. Retrieved from http://ebookcentral.proquest.com Created from apus on 2018-03-19 16:25:53.

C o p yr

ig h t ©

2 0 1 4 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

DATABASES AND UNDERLYING DATA CONTROLS 52 · 5

Business Function Business Role Technology Application or database role

Add new account Phone representative

Insert into certain tables

App: phone rep DB: phone rep

Update account Phone rep (with review) or data input associate

Update certain tables App: update account DB: update account

Confirm phone representative

Phone rep manager

Read certain tables Update certain tables

App: phone rep manager DB: phone rep manager

Once the business requirements are defined and put into a matrix, it becomes much easier to manage existing functions and any future changes and to understand where the critical functions are to grant only the required privileges.

52.4 DATABASES AND UNDERLYING DATA CONTROLS. Database tech- nology allows for granular control of information though the use of role-based access controls (RBAC), as discussed in Chapter 9 in this Handbook. In addition, databases provide a multifaceted approach to application control. Not only can all users be seg- regated based on business need, but the database design can provide a level of control using table design and layout. Good database design and use can help protect data security. Relational databases are based on an underlying theoretical model by E. F. Codd, developed in the 1970s, and widely used today and for the foreseeable future.

Relational database management systems (RDBMS) are sets of programs that pro- vide database administrators (DBAs) with the tools to perform the following tasks:

� Create database structures (file or table layouts, and screens or forms). � Enter information into the structures. � Establish cross-references among the files or tables. � Manipulate (sort, index, and summarize) the information in the structures. � Import information from nonrelational database structures and export information to nondatabase structures. This allows for interfaces between applications using an RDBMS, and applications using conventional files structures

� Data-repository and data-dictionary tools. These tools document databases and may include descriptive information (metadata) about all of the resources included in an information-systems environment. Data dictionaries can support documen- tation standards. Common file or table structures, common program modules, and common field definitions contribute significantly to the reduction of confusion, and of communication breakdowns in an enterprise

� Databases move much of the dynamically changing requirements for data formats and data edits out of the source code of application programs and into easily localized and edited single criteria. Instead of having programmers hunt down and alter multiple occurrences of data restrictions, DBAs can collaborate with the programmers to change individual criteria with the assurance that all programs using the RDBMS will successfully execute the changes.

All of these tools help maintain the security and the integrity of the database.

Bosworth, S., Kabay, M. E., & Whyne, E. (Eds.). (2014). Computer security handbook, set. Retrieved from http://ebookcentral.proquest.com Created from apus on 2018-03-19 16:25:53.

C o p yr

ig h t ©

2 0 1 4 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

52 · 6 APPLICATION CONTROLS

There are two primary methods of organizing files and databases for access and processing: batch and online. Batch files, which can be written in various job-control languages (JCLs), carry out instructions without further human intervention once they are set in execution, whereas online methods involve human interaction with the programs at multiple points. Protection of online files and databases requires additional planning when the systems using them are being architected and special precautions when they are being used. Protection of batch files is more straightforward because the creation of backup copies is an inherent part of the batch process.

As previously discussed, data validation prior to entering information into a database must be completed regardless if the entry is via user or system. Every attempt should be made to assure that data are entered or transferred and validated expeditiously. Failure to get correct data into a system quickly delays the creation and display of the information, the very purpose of almost all systems. When improper attention is directed to validation of the data as it enters the system, incorrect information is created by the system. The acronym GIGO (garbage in, garbage out) has long become part of the national lexicon of everyday language. Improper validation and allowing of garbage into a database may have downstream impact to other applications or processes that use the data. Validation at all tiers of an application is critical.

For related topics, see Chapter 38 in this Handbook on writing secure code, Chapter 39 on software development and quality assurance, Chapter 40 on managing software patches, and Chapter 47 on operations security and production controls.

52.4.1 Data Corruption. Data corruption implies incorrect data—a violation of the integrity of the data. Corruption can occur because of physical factors or logical errorsinprograms. Goodapplicationcontrolsdictate that databasesandtheir underlying architecture be protected from data corruption. Data can be damaged through hardware problems, errors in software, or during concurrent access by two or more users or processes.

52.4.1.1 Physical Data Corruption. Physical corruption occurs through breakdown or other failures of hardware such as computers and network equipment, especially of mass-storage devices such as magnetic disks, tapes and cartridges, or optical drives. Data corruption during transmission can occur through electromagnetic perturbations of communications cables or radio-frequency noise that affects wire- less transmission. Fiber-optic cables are susceptible to cross-talk and to disruption caused by physical bends or kinks in the cables; optical disks are susceptible to dirt and abrasion; magnetic disk drives can be harmed by physical jolts (dropping, intense vibration); solid-state drives do not do well when immersed in liquid.

In addition to problems in the transmission or storage media, improper settings or the effects of wear in the equipment can cause errors. Examples include misalignment of magnetic heads on disks and tapes; bad contacts in wireless transmission equipment, causing noise; and improper positioning of lasers in optical media. See Chapters 22 and 23 for extensive discussion of physical factors that can cause data corruption.

Physical corruption characteristically shows data written inappropriately across blocks, rather than in single fields defined by software applications. Such physical corruption usually has no relationship with the damaged records other than physical proximity on the disk; therefore, a cardinal sign of physical corruption is damage to files from completely different applications—a block of database records contiguous to a block of text files, for example.

Bosworth, S., Kabay, M. E., & Whyne, E. (Eds.). (2014). Computer security handbook, set. Retrieved from http://ebookcentral.proquest.com Created from apus on 2018-03-19 16:25:53.

C o p yr

ig h t ©

2 0 1 4 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

DATABASES AND UNDERLYING DATA CONTROLS 52 · 7

52.4.1.2 Logical Data Corruption. Logical corruption occurs through pro- gramming errors such as incorrect sums, bad arithmetic formulas, incorrect logical conditions, bad data in look-up tables, out-of-bounds conditions allowing reading and writing in the wrong areas of memory, lack of data validation, and the effects of ma- licious software. See Chapter 38 in this Handbook for a discussion of many types of such errors.

Logical corruption characteristically shows errors in the same field in multiple records. Another class of logical errors shows bad values for boundary conditions (e.g., the smallest or largest possible value) but correct data within the range. Such errors rarely cross application boundaries unless there is a logical relationship among the damaged files; for example, an error in a spreadsheet (almost always due to input or programming errors by the user) may propagate to text files if object linking and em- bedding are used to insert the spreadsheet results into the document. Other documents will remain unaffected by such logical errors.

For more extensive discussion of preventing, locating, and correcting logical errors, see Chapter 39 on software development and quality assurance.

52.4.2 Database Management Subsystems. In the 1960s, complex sys- tems, such as those based on accounting records, forced programmers to define their own file structures to represent relationships among the data; for example, an order header file would be linked to the corresponding order detail records through hard- coded relationships in the application programs. Each programmer or programming team had to define its own data access paths and code them explicitly. Coordinating access to multiple individually named files caused headaches for programmers. For ex- ample, it was easy to make errors such as forgetting to increment counters representing how many detail records corresponded to a master (index) record (e.g., line counts in order headers disagreeing with the actual number of detail lines). Because there was no particular protection for the files in such systems, it was easy to replace or delete individual files by mistake, leading to massive logical corruption. Deletion of header records could leave a fragment of inaccessible details (orphans) in associated files. Programs had to keep pointers up-to-date for forward and backward chaining. Backups sometimes failed through operator error so that not all related files were included. Furthermore, every system had its own unique methods for managing the data, causing maintenance and learning headaches.

The late 1960s saw many large programming shops defining their data access meth- ods by using library routines that all programmers could share, but there was still a heavy investment in learning the new rules whenever a programmer changed jobs. Fol- lowing the publication of E. F. Codd’s model for relational databases in the early 1970s, the programming field saw explosive growth in implementation of database manage- ment subsystems, where the interface to the database controlled utility functions such as indexing, pointing, and chaining.

With proper configuration a typical DBMS protects all files, called datasets, against accidental erasure, and would force all reads, writes, appends, and locks to be mediated by the DBMS routines. General users should not have access to a DB’s underlying infrastructure—only to the data through the DBMS.

The DBMS provides controlled access to data and also typically provides backup utilities to ensure that all datasets are copied together and to prevent accidental restora- tion of the wrong version of a dataset. Finally, a DBMS usually provides logging

Bosworth, S., Kabay, M. E., & Whyne, E. (Eds.). (2014). Computer security handbook, set. Retrieved from http://ebookcentral.proquest.com Created from apus on 2018-03-19 16:25:53.

C o p yr

ig h t ©

2 0 1 4 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

52 · 8 APPLICATION CONTROLS

facilities to keep records of different types of access to the database. All of this func- tionality provides control to the data.

One of the most important rules enforced by a DBMS is referential integrity to prevent common logical data corruption, automatic uniqueness constraints to preclude duplicate and conflicting records, and locking for safe concurrent access.

� Referential Integrity. Referential integrity in DBMS design ensures that every dependent record has a primary key value that matches an existing primary key in the master file. � In an order database, for example, order numbers in a header file (often called the order master) are the primary keys.

� Each order header record contains unique information about an order, such as customer number, date placed, total price of materials, taxes, and shipping costs.

� The order detail file contains the dependent records, each of which can be located using its order number as the primary key.

� Each detail record contains information about a specific part of the correspond- ing order such as an item number, quantity ordered, price, extended price, and special charges or discounts.

� If an order header record is to be deleted, all the order detail records must first be deleted; otherwise, the detail records would be left with no way to locate them through their primary key value.

� Similarly, no detail record can be added unless the master record with the same primary key already exists.

� Uniqueness Constraints. A modern DBMS allows configuration of nonrepeating primary keys; for example, in an order database, the order number would typically be a nonrepeating or unique key because there should never be two orders with the same identifying number. Setting the uniqueness property would preclude adding a second header record with the same value in the order number field as another order.

52.4.3 Distributed Databases. A distributed database is one that is stored in different databases on different computer platforms. Databases can be distributed over many sites, using several different architectures.

The simplest and most susceptible to failure is the single database server that houses the database and shares its contents among several local area networks. Whenever the server or the database is offline, or during a crash, all clients lose access to the database. The backup and recovery of a single-server database follows the procedures described earlier.

A second architecture is the replicated database server, in which there are duplicate copies of the database on multiple servers. This type of system allows clients to access information from any of several copies of the database. With a replicated server environment, clients can still have access to the database, when one of the servers is offline. Such replicated systems usually have an additional benefit of being able to balance transaction traffic so as to keep any one server from being overwhelmed. The trade-off is the database synchronization process that increases the complexity of the replicated server architecture. Although the backup and recovery of a distributed database can also follow the procedures described earlier, it is complicated by the synchronization requirement.

Bosworth, S., Kabay, M. E., & Whyne, E. (Eds.). (2014). Computer security handbook, set. Retrieved from http://ebookcentral.proquest.com Created from apus on 2018-03-19 16:25:53.

C o p yr

ig h t ©

2 0 1 4 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

DATABASES AND UNDERLYING DATA CONTROLS 52 · 9

A third architecture is known as a partitioned database server, in which specific subsets of a database are on two or more database servers. There could be a marketing database on one server, an accounting and finance database on a second server, and an inventory database on a third server. Because it is generally not possible to have mutually exclusive subsets of databases, synchronization must still be part of this architecture. Backup and recovery of partitioned databases requires application of the procedures described above for each of the subsets.

There is another distributed architecture known as federated database servers. This architecture is used in support of databases on two or more servers, made up of ordinar- ily incompatible storage models such as hierarchical and relational models supported by different DBMSs. With the federated architecture, a single unified database defini- tion, or schema, is created and stored on a combined database server. That server acts as an interface between application programs and the databases residing on the other servers. Queries and other transactions are sent to the combined database server, which translates these into queries and transactions to the underlying databases. Responses then return from the underlying databases to the unified schema to formulate a response to the user. Backup and recovery procedures such as those described above are used for the underlying databases.

Although federated database architecture can be complex and expensive to maintain, it can be less complex and less expensive than the process of supporting application programs for each of the underlying DBMSs. Federated architecture is often used in the implementation of data warehouses, which are used to extract information from multiple internal databases, as well as external databases, to support management decision making.

52.4.3.1 Database Controls to Maintain Integrity. Concurrent access to data can cause problems of integrity unless the access is serialized to ensure that one process at a time accesses any given resource.

52.4.3.2 Lock on Update. When more than one user accesses a database, it is possible to experience conflicts over the use of specific records. A classic example occurs in an inventory database, where there are 15 units of part 1 in the inventory.

� User Albert needs to take five units of part 1 out of inventory, leaving a total of 10. The inventory program reads the inventory record for part 1 and modifies record 1 to show only 10 units.

� However, if while this is going on user Betty needs three units of part 1, the inventory record still shows 15 units available because user Albert has not yet updated that record.

� After user Albert’s program completes its update, the record shows 10 units avail- able, but after user Betty’s program overwrites that record to show 12 available units for part 1, the inventory total is off by five units.

� This situation is an example of a race condition as described in Section 39.4.1.6 of Chapter 39 in this Handbook.

To avoid this kind of logical corruption, a DBMS provides facilities for locking parts of the database. In the inventory example, user A’s program would lock the inventory record for part 1 (or the entire inventory dataset) until the update is completed. That

Bosworth, S., Kabay, M. E., & Whyne, E. (Eds.). (2014). Computer security handbook, set. Retrieved from http://ebookcentral.proquest.com Created from apus on 2018-03-19 16:25:53.

C o p yr

ig h t ©

2 0 1 4 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

52 · 10 APPLICATION CONTROLS

way, user B’s program would have to wait for user A’s program to unlock the data before being able to act on the inventory record.

The obvious symptom of a bad locking strategy is a discrepancy between the database value and the real-world value. However, such a discrepancy is not by itself proof of logical corruption, because the same divergence could arise from events in the real world not reflected in the database. In the inventory example, the actual inventory may have been reduced by theft, or increased by an unrecorded addition of materials.

52.4.3.3 Unconditional versus Conditional Locking. There are twotypes of locking strategy: conditional locking and unconditional locking.

� Conditional locking attempts to obtain a lock, but if the required record or the entire dataset is already locked, the DBMS returns control to the calling program with a status indicator of this condition. The application program can then be written to loop until the lock is obtained.

� The unconditional lock request hangs the program until the lock is granted. The DBMS or the operating system provides automatic queuing using a first-in, first- out queue.

52.4.3.4 Deadlocks. Unconditional locking carries risks if multiple resources are locked by programs.

� For example, if program A unconditionally locks resource 1 and program B locks resource 2, trouble will occur when program A then attempts to lock resource 2, while program B tries to lock resource 1.

� Neither program will release the resource it has locked until it is released, and so both will wait forever or until one of the programs is forcibly terminated.

� Such a situation is known as a deadlock or more colorfully as a deadly embrace. � If programmers insist on using unconditional locking, the deadlock prevention strategy is to ensure that all programs accessing the database must lock resources in the same order (e.g., lock 1, then lock 2) and must unlock in the reverse order (unlock 2, then unlock 1).

Other strategies are to keep transactions as short as possible, and to avoid the necessity for operator interactions that would keep the records locked for long periods of time.

52.4.3.5 Two-Phase Commit. Sometimes many records or datasets must be locked for complex transactions to be completed. For example, in a hospital’s clinical systems database, discharging a patient could require modifications in datasets such as the patient-master, treatment-detail, nursing assignment master and details, doctor assignment master and details, and datasets for the financial functions. Locking every- thing that might be needed and waiting for a human being to enter all the appropriate data could take seconds to minutes, during which all the affected records would be locked and unavailable to everyone else on the system. In the extreme, if an operator were to leave in the middle of a transaction, other users could be blocked out of large parts of the database for an indeterminate length of time, even for hours. The delays resulting from such locking around human intervention led to the principle that no transaction can be allowed to lock around a human intervention.

Bosworth, S., Kabay, M. E., & Whyne, E. (Eds.). (2014). Computer security handbook, set. Retrieved from http://ebookcentral.proquest.com Created from apus on 2018-03-19 16:25:53.

C o p yr

ig h t ©

2 0 1 4 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

DATABASES AND UNDERLYING DATA CONTROLS 52 · 11

Another problem with locking around human intervention is that a system failure could terminate processing while the database was in an inconsistent state. For example, in the inventory case, the DBMS might have updated the order detail by adding an item, but not yet updated the order header to show the new total cost of the order. To reduce the likelihood of such an occurrence, a DBMS can support the two-phase commit as an aid to making changes as fast as possible, and thus reducing the window of vulnerability for interruption.

� In the two-phase commit, the DBMS obtains copies of all the records needed when the operator begins a transaction.

� Once the operator has taken all necessary steps for completing the transaction, the DBMS locks and reads all the changed records again and compares the current values with the initial values; if there are no differences, the DBMS makes all the required changes and immediately unlocks all the records.

� However, if the current values have been modified since the operator requested the initial copies, then some other process has been active and so the DBMS reports that verification is needed.

� The operator is typically given the choice of how to proceed; for example, if there are no items left in inventory, the order may have to be delayed or can- celed, whereas if there are enough items, the operator need merely reinitiate the transaction with the new initial values.

52.4.3.6 Database Backup Files and System Logs. When information in an online file or database is updated, the old information, that is, the information that was in the record before the change was made, is overlaid; unless steps are taken, it disappears without a trace. For this reason, many DBMSs allow an image of the original record to be copied to the transaction log file. In other cases, where the exact history of a particular group of records must be preserved, as with insurance and medical data, an application may append new records but not delete old ones.

If online files and databases were never damaged or lost, data loss would be of no concern with proper database configuration. However, in an imperfect world, steps must be taken so that damaged or lost online files and databases can be recovered. For further details of data backup and recovery, see Chapter 57 in this Handbook.

In order to recover online files and databases, it is first necessary to make periodic backup copies, and to make log copies of records that have been updated in the time between making the backups. How often a backup copy is made depends on how dynamic the files or databases are. In most enterprises, a significant number of total or partial files and databases are copied daily. It is not uncommon for computer operations departments to spend several hours each day doing backups. Whenever a backup copy of a file or database is created, there are two correct copies at that point in time. To explain how online file and database backup and system logging work, think of a single online file. The file is taken offline, and is no longer accessible to online transactions at 4 AM, and a copy is made. Both copies of this file are identical at that time. At 6 AM, the backup is complete and the original disk file is put back online. Transactions start to update that file again. From that point on, with each update transaction, the differences between that file and its backup increase.

At 2 PM, if for some reason the file is no longer usable, the backup file is then eight hours behind. At this point, the log file becomes critical in the restoration process. The

Bosworth, S., Kabay, M. E., & Whyne, E. (Eds.). (2014). Computer security handbook, set. Retrieved from http://ebookcentral.proquest.com Created from apus on 2018-03-19 16:25:53.

C o p yr

ig h t ©

2 0 1 4 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

52 · 12 APPLICATION CONTROLS

log file is in sequence by time and contains copies of the updated records both before and after update was performed. It also contains copies of the transaction record.

52.4.4 Recovery and Restart. After it has been determined that an online file or database has been corrupted or destroyed, a procedure known as recovery and restart is initiated. The first step in this procedure is to copy the backup back to disk to create a new original as of the time of that backup. The next step uses the log file to reapply, in time sequence, all the transactions that had been executed since the backup copy was made.

Contemporary database systems may have files that cannot be taken offline. They are online 24 hours a day, seven days a week. In order to make backup copies, parts of the database are copied periodically (dynamic backup). Conceptually, a database can be broken up into parts. Each part can be backed up separately at different time periods. A number of schemes can be devised to back up some of the records. For example, copy to a backup file every fifth record of the database in one time period, say records 5, 10, 15, 20, etc. A bit later, copy to another backup file records 1, 6, 11, 16, 21, and so on. If a conflict occurs between copying the record for backup and a transaction attempting to update the record, have an appropriate procedure established to let one or the other take place first. Recovery and restart, as well as backout procedures, work the same way, with the additional complexity of establishing priorities for which gets done first when conflicts occur. Even though these conflicts increase complexity, they are resolved when the procedures for recovery, restart, and backout are created.

Another approach to backups of such critical files is the shadow copy, which copies data even when files are in use. Shadow copy software bypasses elements of the file system to be able to access locked records.

52.4.4.1 Backout. The log file is also used in a process known as backout. This process is initiated when online update transactions fail to complete after making in- complete or partial updates to files or databases. For example, an update transaction in which there are additions to three fields in three separate files is supposed to take place. After making two out of the three updates, the transaction terminates abnormally be- cause of a program malfunction. Eventually, the program gets corrected, but something has to be done to undo the two partial updates. Otherwise, when the program is fixed and the transaction is rerun, those two updates would be reapplied, which would re- sult in erroneous duplication. The backout procedure is initiated for those transactions which, if they had not completed properly, would generate errors.

Recovery, using log files, requires marking the start and end of every transaction; if the log file records show a transaction start without the corresponding transaction end, recovery processes can recognize the transaction as incomplete. Such markers correspond to what are called checkpoints in the program design.

52.4.4.2 Roll-Forward Recovery. Another approach to recovery is to start from a known good state and redo all transactions that are known to have been ac- complished correctly. This roll-forward recovery requires a database backup and a transaction log file to be synchronized, so that the first record in the transaction log file represents the first transaction immediately following a database backup. With these data in hand, it is possible to reconstruct all the modifications up to, but not including, the last complete transaction. All incomplete transactions are discarded, although the recovery program typically prints out all the details available for transactions that were not completed.

Bosworth, S., Kabay, M. E., & Whyne, E. (Eds.). (2014). Computer security handbook, set. Retrieved from http://ebookcentral.proquest.com Created from apus on 2018-03-19 16:25:53.

C o p yr

ig h t ©

2 0 1 4 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

DATA INTEGRITY AND VALIDATION 52 · 13

52.5 BATCH FILES. Operating systems have their own facilities for writing and executing batch files, sometimes called scripts. Batch files can be complex enough that they look like programs, with logical tests, branching, and so on.

52.5.1 Backup File Creation. The protection of files that are updated by batch processing programs is automatic, because the file is completely recopied and the original is left in the form it was in before the program executed. Therefore, each processing cycle leaves its own backup. The name batch processing comes from the idea of sequentially processing transactions in a group. There are always two or more files involved. There is the master file that is being updated, and one or more transaction files that contain the information used to update the master. The process copies master file records that have no update activity into a new master file, updates the master records that do have activity and copies them into the new master file, and does not copy those master records that are flagged as deletions in the activity file. When the process completes, there are at least three files: the original master, the activity file(s), and the new master. Backups are the original master and the activity file(s). In the next processing cycle, the new master becomes input, together with that cycle’s activity file(s). If a problem is encountered with the master file, the prior cycle’s master file and all subsequent activity files can be used to generate an updated master. Keeping two or three generations of master and activity files is a common practice. The term generation is often applied to the batch processing cycles—generation 0, generation 1, generation 2—or as grandfather, father, and son. In recent decades, these latter terms have been replaced by grandparent, parent, and child.

52.5.2 Audit Controls. Another security measure applied when working with batch files involves using control totals to assure that the batch process has executed with accuracy. Specific controls may include counts of records. There also may be control totals of the values in specific fields of the input records to compare with totals in the output, after processing additions and subtractions. For example, in a payroll system, information from time cards is submitted to a computer for processing. Along with the time cards is a transmittal that contains a count of the time cards, and totals of all the straight time and overtime hours compiled by the department that originated the time cards. A procedure is run in which the control totals on the transmittal are checked against the totals actually input from the time cards, to assure correctness before initiating the payroll process. If discrepancies are encountered, they need to be investigated and corrected before taking the next step in processing the payroll.

52.6 DATA INTEGRITY AND VALIDATION. The following sections present a brief overview of validation; however, for more extensive coverage of this topic, see Chapter 47 in this Handbook on operations security and production controls.

52.6.1 Validation Controls. Whether an application updates its files by means of batch or online processing, or in some combination of both, validation of input is paramount. The term GIGO (garbage in, garbage out) is not heard as often as it used to be, yet it is as true as ever. Most contemporary systems use online files and databases, with information entered interactively, allowing for validation at the source. There are several specific validation techniques that have been applied to reduce the amount of incorrect information input into files and databases.

Bosworth, S., Kabay, M. E., & Whyne, E. (Eds.). (2014). Computer security handbook, set. Retrieved from http://ebookcentral.proquest.com Created from apus on 2018-03-19 16:25:53.

C o p yr

ig h t ©

2 0 1 4 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

52 · 14 APPLICATION CONTROLS

52.6.1.1 Methods for Identifying Input Errors and Unauthorized Modifications

Data input errors are common. � Fours and nines, ones and sevens, and sixes and zeros can easily be mistaken for one another.

� Operators can leave out a digit or insert an extraneous one. � Transposition is another type of mistake that is made from time to time. For example, an order entry operator may key in 3286 instead of 3826 (a transposition error), or perhaps 7790 instead of 7796 (a transcription error).

� Such errors would be reported when the checkdigit calculation produces a number that differs from the input check digit.

� A check digit is an extra digit that is added to a generated variable as a suffix. � For example, a five-digit stock number could have an extra digit; the sixth digit or check digit, as it is called, is calculated by applying an algorithm (performing some arithmetic) on the first five digits, resulting in a single-digit result.

� To minimize input errors, check digits can be used on any variables that are program generated; for example, part numbers, employee numbers, and codes of various types.

A single check digit can sometimes conceal the existence of double or multiple input errors in an input string because of the relatively simple arithmetic schemes. More complex versions of the check digit generate a sequence of digits called a checksum, which provides greater power to help identify input errors or fraud; credit card numbers typically include a four-digit checksum at the end of the number. For example, a typical VISA credit card number has the format 1111 2222 3333 4444; the fourth block (4444 in our example) is calculated using a secret algorithm as a function of the other three blocks. Computer criminals have often tried (and sometimes succeeded) to reverse engineer the checksum algorithm to create VISA numbers that actually belong to unknown victims. Credit card security organizations have learned to apply complex heuristic methods to identify unlikely transactions; e.g., if the legitimate owner has just filled up her gas tank at an often-used filling station in Vermont, it is unlikely that a transaction five minutes later for 1,000 wool blankets at a manufacturing firm in Italy is legitimate, regardless of the accurate-looking VISA number.

An extension of the checksum, the hash total, is a common tool for identifying logical or physical data corruption. A hash total is simply the meaningless sum of numerical values, such as part numbers, rather than the meaningful sum of quantities. Recalculation of a hash total can usually indicate if the data have been corrupted since the last time the hash total was computed.

A digital signature is a cryptographically generated value based on an encryption key. Applying the same digital signature process to the data should generate an identical signature. In addition, as described in Chapters 7 and 37 in this Handbook, using the public key cryptosystem allows one to verify the authenticity as well as the integrity of signed data.

52.6.1.2 Range Checks. Range checks offer another way of validating in- formation at its source. In situations where quantities and currency values are being entered, lower and upper limits can be established. For example, a range check could

Bosworth, S., Kabay, M. E., & Whyne, E. (Eds.). (2014). Computer security handbook, set. Retrieved from http://ebookcentral.proquest.com Created from apus on 2018-03-19 16:25:53.

C o p yr

ig h t ©

2 0 1 4 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

DATA INTEGRITY AND VALIDATION 52 · 15

be used on quantity ordered to ensure that the value entered is within specific bounds, such as no less than 10 or no more than 60 of a certain item. Although not completely error proof, such limits can at least eliminate obvious errors and reduce those not so blatant. Range checking with values of 10 and 40 will eliminate the extra 0 error, where an operator enters 100 or 600, or 1 or 4.

52.6.1.3 Validity Checks Using Tables. Using tables of values or valid codes is one of the best ways to ensure that only correct information is entered into files and databases. In contemporary files and databases, data type is specified as a property of the field during the design phase, and these properties can be used to make sure that text information is not entered into numeric fields and vice versa. Properties are also used to filter out invalid data configurations. Although impossible to filter out misspelled last names and other open-ended types of information, it is possible to filter out invalid state codes and other violations of standards. For example, a table containing the valid state codes in a country can be used to assure that none but those codes can be entered in the state field. Other such entities (e.g., department codes, product codes or types, and price classes) are primary candidates for table validation.

With tables, it is also possible to make combination tables. For example, if a certain product code fell within a specific range, then only four price classes might be allowable. To be concrete, suppose that when a product code falls within the 600 to 699 range, then the price class could only be R, PR, OC, and CD. Such tables are used to validate information as it is initially entered into files and databases. Entry of invalid information, whether intentional or inadvertent, is inhibited.

Tables of forbidden combinations are particularly important in real-time control systems for processes that can go seriously wrong as a result of bad inputs. For example, in December 1992, an explosion at a chemical plant in the Netherlands was traced to a data input error that could have been prevented by an edit check that verified a table of forbidden chemical mixtures. The following is an excerpt from a report published in RISKS 14.22 (January 4, 1993) by Meine van der Meulen of The Netherlands Organization for Applied Scientific Research, Department of Industrial Safety:

The accident started with a typing error in a prescription by a Laboratory worker. Instead of tank 632 he typed tank 634. In tank 632 there was stored resin feed classic (UN-1268) and normally used in the batch process. In tank 634 DCDP (dicyclopentadiene) was stored. The operator, who had to check if the tank contents was [sic] equal with the prescription, filled the reactor with the wrong chemicals.

… a heavy explosion occurred which caused the death of 3 firemen of the works fire brigade and injured 11 workers [including] 4 firemen of the works fire brigade. The damage was estimated at several [10s] of millions NL guilders.

Tables should generally be used only for information that is relatively static, because of the need for maintenance. Frequent table maintenance can lead to errors that have a cascading effect. If a table is incorrect, then all the information supposedly validated by that table could be incorrect throughout the files and databases.

52.6.1.4 Diagnostic Utilities. Production programs need to operate on ver- ifiably correct data. Every production program should include diagnostic utilities to scan databases for logically impossible values or deviations from reality. For example, a diagnostic routine might check to be sure that every header total matches the total computed from the linked line item values. Because older data may have been accepted

Bosworth, S., Kabay, M. E., & Whyne, E. (Eds.). (2014). Computer security handbook, set. Retrieved from http://ebookcentral.proquest.com Created from apus on 2018-03-19 16:25:53.

C o p yr

ig h t ©

2 0 1 4 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

52 · 16 APPLICATION CONTROLS

under older range-validation rules, all records should be checked to ensure that they conform to the current range constraints. Similarly, any other logical constraints in an application system should be explicitly addressed in the diagnostic program. The output from the program should give all the details appropriate for identifying and correcting the incorrect data. For example, instead of simply indicating “BAD VALUE IN PRICE FIELD, RECORD 1234,” the output should explain something like, “PRICE FOR ITEM 234 = $45.67 WHICH EXCEEDS CONFIGURED LIMIT OF $40.00 SHOWN IN INVENTORY MASTER RECORD 78999.”

52.7 CONCLUDING REMARKS. In another application of the 80/20 rule, 20 percent of the design and development work is expended in handling 80 percent of the data (the normal and the correct) going through a system, whereas 80 percent of the design and development work is expended for handling 20 percent of the data (the errors, the exceptions, and the unusual situations) going through the system. It is safe to say that more effort should be expended on validation, and on backup and recovery procedures, than is spent on those processes that handle validated data and the routine tasks of application processing.

Good application controls involve data validation at all tiers of an architecture as well as careful consideration of the entitlements granted to users from an application, systems, and database perspective. It is not enough to focus only on user input and trust input from other systems. In today’s complex systems there are too many areas where data can be modified either accidentally or maliciously to trust any input without validation.

In addition, organizations need to leverage all of the features of database systems to help not only maintain integrity, but understand data backup and recovery mechanisms. Adequate backup and recovery processes and procedures have to be put in place to handle system failures. These processes and procedures range from disaster recovery to single system or application recovery. To ensure that sites, enterprises, or applications can be brought back after failures requires that processes and procedures be put in place during the design and development process and kept up to date as the situation requires.

52.8 FURTHER READING Basta, A., and M. Zgola. Database Security. Cengage Learning, 2011. Chadli, M., and H. Coppier. Command-control for Real-time Systems. Wiley-ISTE,

2013. Jones, C. Software Engineering Best Practices: Lessons from Successful Projects in

the Top Companies. McGraw-Hill Osborne Media, 2009. Kroenke, D. M., and D. Auer. Database Processing, 12th ed. Prentice-Hall, 2011. Lublinksy, B., K. T. Smith, and A. Yakubovich. Professional Hadoop Solutions. Wrox,

2013. Ottenheimer, D. Big Data Security. Wiley, 2014. Post, G. V. Database Management Systems: Designing and Building Busi-

ness Applications, 5th ed. Self-published, 2010. http://jerrypost.com/Books/ DBBookSummary.html

Radvanovsky, R., and J. Brodsky, eds. Handbook of SCADA/Control Systems Security. CRC Press, 2013.

Romney, M. B., and P. J. Steinbart. Accounting Information Systems, 12th ed. Prentice- Hall, 2011.

Bosworth, S., Kabay, M. E., & Whyne, E. (Eds.). (2014). Computer security handbook, set. Retrieved from http://ebookcentral.proquest.com Created from apus on 2018-03-19 16:25:53.

C o p yr

ig h t ©

2 0 1 4 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

FURTHER READING 52 · 17

Shelley, G. B., and H. J. Rosenblatt. Systems Analysis and Design, 10th ed. Cengage Learning, 2013.

Sommerville, I. Software Engineering, 9th ed. Addison Wesley, 2010. Stair, R. M., and G. W. Reynolds. Principles of Information Systems, 11th ed. Cengage

Learning, 2013. Van Wyk, K. R., and M. G. Graf. Enterprise Software Security: A Confluence of

Disciplines. Addison-Wesley Professional, 2014.

Bosworth, S., Kabay, M. E., & Whyne, E. (Eds.). (2014). Computer security handbook, set. Retrieved from http://ebookcentral.proquest.com Created from apus on 2018-03-19 16:25:53.

C o p yr

ig h t ©

2 0 1 4 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

Bosworth, S., Kabay, M. E., & Whyne, E. (Eds.). (2014). Computer security handbook, set. Retrieved from http://ebookcentral.proquest.com Created from apus on 2018-03-19 16:25:53.

C o p yr

ig h t ©

2 0 1 4 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

53CHAPTER

MONITORING AND CONTROL SYSTEMS

Caleb S. Coggins and Diane E. Levine

53.1 INTRODUCTION 53 · 2 53.1.1 Prevention, Detection,

and Response 53·3 53.1.2 Controlling versus

Monitoring 53·3 53.1.3 Control Loop 53·5 53.1.4 Defining the Scope

and System Requirements 53·5

53.2 SYSTEM MODELS 53 · 6 53.2.1 Internal, One-to-One,

One-to-Many, and Distributed 53·6

53.2.2 Automation and the Human–Machine Interface 53·7

53.2.3 Snapshots versus Real Time 53·8

53.2.4 Memory Dumps 53·9

53.3 LOG MANAGEMENT 53 · 11 53.3.1 Log Generation 53·11 53.3.2 Types of Log File

Records 53·11 53.3.3 Automation and

Resource Allocation 53·15 53.3.4 Log Record Security 53·15

53.4 GENERAL LOGGING CLASSES 53 · 17 53.4.1 Overview 53·17 53.4.2 Process Flow and

Job Scheduling 53·17 53.4.3 Network

Connectivity 53·17

53.4.4 Environmental Concerns 53·18

53.4.5 System State 53·18 53.4.6 System Components 53·19 53.4.7 Process Activities 53·19 53.4.8 File System 53·20 53.4.9 Access Controls 53·20

53.5 DATA AGGREGATION AND REDUCTION 53 · 21 53.5.1 Centralized Data

Stores 53·21 53.5.2 Filtered Queries 53·21 53.5.3 Analyzing Log

Records 53·21

53.6 NOTIFICATIONS AND REPORTING 53 · 22 53.6.1 Alerts 53·22 53.6.2 Trend Analysis and

Reporting 53·23 53.6.3 Dashboards 53·24

53.7 CHANGE AND SECURITY IMPLICATIONS 53 · 24 53.7.1 Change

Management 53·24 53.7.2 Configuration

Protection 53·25 53.7.3 Performance

Considerations 53·25

53.8 MONITORING AND CONTROL CHALLENGES 53 · 25 53.8.1 Overview 53·25 53.8.2 Industrial Control

Systems 53·26

53 · 1 Bosworth, S., Kabay, M. E., & Whyne, E. (Eds.). (2014). Computer security handbook, set. Retrieved from http://ebookcentral.proquest.com Created from apus on 2018-03-19 16:25:53.

C o p yr

ig h t ©

2 0 1 4 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

53 · 2 MONITORING AND CONTROL SYSTEMS

53.8.3 Mobile Computing 53·27 53.8.4 Virtualization 53·27 53.8.5 Cloud Computing 53·28

53.9 SUMMARY 53 · 29 53.9.1 M&C Checklist 53·29

53.10 FURTHER READING 53 · 30

53.11 NOTES 53 · 31

53.1 INTRODUCTION. Monitoring and control (M&C) systems provide critical services to computing operations through prevention, detection, and response. When aligned with security policy and appropriately implemented, these systems enable organizations to detect security incidents, mitigate risk, and analyze trends. M&C systems may prevent persistent unauthorized login attempts from a remote location, detect performance issues on a storage network, or alert an incident responder to the attempted theft of intellectual property. Automation is a key factor for proactive, real- time, and scalable M&C system implementations. Although it is possible to review individual log files within a limited scope, manual log review remains impractical and inefficient for modern enterprises processing millions of events on a routine basis. Although the scope of M&C systems may vary in size and complexity, the central components remain the same: data collection, data reduction, and system response. Data collection includes log file generation and storage. Computer systems use log

files to store records of events. Logged information includes system time, relevant user accounts, system identifiers, and the actions performed. Programs write or append data to log files that are often stored in local directory structures and forwarded to central log collectors for aggregation. Data reduction is the process of using predefined or on-demand rules and logic

to generate relevant, filtered, and actionable views of aggregate log data. Exception reports such as failed or unauthorized login attempts filter out acceptable events, enabling analysts and automated alert processes to focus on anomalies for additional follow-up. Visual dashboards, including performance metrics and risk-ranked events, provide information managers and production operators with an enterprise view of current production activities that may impact service delivery objectives. System response encompasses the actions resulting from the data reduction phase.

Actions include alert notification, corrective actions, and recovery procedures. Depend- ing on several factors, the response may be automated or involve feedback through a human–machine interface (HMI).

The following self-assessment questionnaire is based on the areas covered in this chapter; it identifies elements to review for an existing or planned M&C system:

� What is the purpose and goal of the M&C system, from a business and technical service perspective?

� What are the security, compliance, business, and legal requirements? � What systems, components, or processes need to be monitored or controlled? � What model will be used to monitor or control the target? � Where will the data be stored? � How will the data records be retained and secured? � What kind of data reduction and reporting is required? � Who or what will respond to detected events and incidents? � What self-defense mechanisms exist for the M&C system?

Bosworth, S., Kabay, M. E., & Whyne, E. (Eds.). (2014). Computer security handbook, set. Retrieved from http://ebookcentral.proquest.com Created from apus on 2018-03-19 16:25:53.

C o p yr

ig h t ©

2 0 1 4 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

INTRODUCTION 53 · 3

53.1.1 Prevention, Detection, and Response. M&C system capabilities generally include the ability to prevent, detect, and respond to a wide number of events. However, not all events and challenges need to be met with costly control systems or dedicated sensors. Some activities may be more suited for monitoring than control. You may also want to alert on activities that may not be alarming on an individual basis but may be significant in aggregate or at specific thresholds. Decisions to implement and configure monitoring and control systems should be founded on a risk-based approach. Prevention refers to the system’s ability to prohibit an undesirable action. Common

tools used in network security include in-line intrusion prevention systems (IPSs) and unified threat management (UTM) appliances. Deploying these systems at choke points, between enclaves, and at the network edge can restrict the proliferation of malware across an enterprise network as well as block Command and Control (C&C or C2) channels for botnet clients. In the physical-security realm, single-person mantraps prevent individuals from tailgating into secure facilities.1

Detection refers to the ability to identify attacks and other security concerns through sensory input. Systems rely on automated detection mechanisms and human obser- vation. M&C systems must have reliable detection mechanisms in order to manage security events and provide meaningful metrics on the state of the information infra- structure. Proactive detection may involve the authorized use of a vulnerability scanner by security controls testers. Reactive detection may include the identification of source IP addresses and VPN users who participated in a distributed denial of service (DDoS) attack on an Internet-facing network.2

Response refers to the output of M&C systems. A monitoring system may detect remote attempts to enable FTP and Telnet on production servers, log the activity, and send an administrative alert to an operator or centralized correlation engine. A control system, however, would correct the configuration files and service states or prohibit the changes from occurring in the first place. Additional human response may occur after the administrative alert or dashboard refresh, such as escalation to an incident-response team for resolution and postmortem analysis.3

Failure to detect and report security breaches within mandated time frames may have legal ramifications, as many states require breach notification.4 Implementing de- fense in depth (layered defenses) increases the likelihood of threat detection, incident prevention, and response. For example, AC power loss at a secure facility and a non- responsive battery or generator backup may render a closed-circuit television (CCTV) system incapable of recording a physical attack. An additional layer, such as physical security guards, can provide a degraded level of monitoring while technicians restore power and monitoring systems to normal functionality.5

53.1.2 Controlling versus Monitoring. Monitoring refers to the observa- tion, logging, and reporting of systems, components, and events. Data collected from monitoring systems may identify intruders, locate system vulnerabilities, confirm op- erational status, and provide confirmation that controls are online and in place. In a network environment, a vulnerability scanner can perform authenticated scans on spe- cific devices to identify missing patches and configuration issues without necessarily modifying or controlling the targets. M&C systems operate in two modes, continuous and batch.

1. Continuous mode provides ongoing measurement and compliance assurance. Systems that operate in real-time, continuous mode present a more accurate, up-to-the-second view of an organization’s operational environment.

Bosworth, S., Kabay, M. E., & Whyne, E. (Eds.). (2014). Computer security handbook, set. Retrieved from http://ebookcentral.proquest.com Created from apus on 2018-03-19 16:25:53.

C o p yr

ig h t ©

2 0 1 4 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

53 · 4 MONITORING AND CONTROL SYSTEMS

2. Batch mode takes place at specific points in time. An annual audit often uti- lizes batch mode analysis, to determine the effectiveness of system controls and processes. The results provide limited assurance for a specific point in time or historical range based on available data.

Control refers to what we can manipulate and audit. Rather than merely observ- ing and recording information about an unauthorized change in the operational envi- ronment, controls can restrict such activities based on predefined configurations and processes. Controls may be prohibitive or corrective in action.

� Prohibitive controls prevent the change from occurring. � Corrective controls return or restore a control target to its approved state. A host intrusion prevention system (HIPS) may prevent modification to critical system files, while logging and alerting on failed attempts to do so.

Control systems ensure that the operational environment reflects stated policies and standards. The Control Objectives for Information and Related Technology (COBIT) section AI1.9 and ISO 17799 section 9.7 identify the need to monitor system access and use (see Chapters 44 and 54 in this Handbook for discussion of these standards).

Organizations that still depend on passwords for authentication should not only es- tablish policies and draft procedures to meet those requirements but also need to imple- ment technical controls to enforce compliance. If the standard includes a 15-character minimum password length, with specific complexity requirements and a mandated limit on the period of validity, technical password controls should prevent users and administrators from defining nonexpiring, short, trivial passwords such as abcde.6

Auditors inspect the operational environment to provide objective assurance of an organization’s control environment. Typically, auditors evaluate a sample of control sets at scheduled intervals. These point-in-time, manual efforts provide insight into the infrastructure’s degree of compliance. However, they do not provide the same level of efficiency as integrating automation into a framework that supports continuous information assurance.

The environment directly affects system security. Temperature, humidity, air qual- ity, and other variables may introduce unscheduled system failures in a work environ- ment. Such variables which may be outside our direct control also require monitoring. Computer system–management applications monitor internal components as well as environmental and equipment temperature and power-supply voltage levels. Most or- ganizations may not be able to control the temperature of an overheating processor or a lack of electricity provided by the utility company, but sensory thresholds in a mon- itoring application may trigger automated scripts or notify local personnel to initiate a system shutdown. In these situations, the monitoring thresholds and alerts provide systems and operators the opportunity to gracefully stop running processes or revert processing to an alternate system or location.

Organizations decide to implement systems with monitoring or control capabilities for a number of reasons including perceived risk, financial costs, logistical difficulties, and business value. For organizations with an immature security program and limited visibility into the operational environment, monitoring can also provide a means of transition to future controls. For example, monitoring can provide baseline data and allow reports on an organization’s resource utilization (e.g., disk space, Internet usage) and provide a basis for effective planning (“We will run out of disk space between

Bosworth, S., Kabay, M. E., & Whyne, E. (Eds.). (2014). Computer security handbook, set. Retrieved from http://ebookcentral.proquest.com Created from apus on 2018-03-19 16:25:53.

C o p yr

ig h t ©

2 0 1 4 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

INTRODUCTION 53 · 5

August and November of next year”) as well as indicating areas for better awareness, training, education, and compliance efforts (“Four of our employees are collectively responsible for 60 percent of our Internet bandwidth utilization—and half of their activity involves watching pornographic videos during working hours!”).

53.1.3 Control Loop. For most environments, humans remain in the control loop. The control loop consists of the controller, the target system, a two-way commu- nication path, and the transmitted data.

The control loop is considered a closed loop when the process is automated and does not require human interaction; an open loop involves human interaction.

The requirements of the system determine the loop type. When gas-pipeline sensors detect a sudden decrease in pressure, an automated control system may need to perform an immediate lockdown to isolate the leak and send alert notifications. Leaving the loop open and waiting for human response may result in undesirable product loss and environmental and legal challenges. For operating-system patch deployment, an open loop would allow a system to interrogate hosts, determine patch levels, and report status for further review and action. A supervisor could then approve specific patches to particular systems after sufficient testing on noncritical, nonproduction systems and coordination with system stakeholders. Although fully automated software patching may seem like a viable process, it introduces additional risk (through system and processdisruptions) andcompatibilityconcerns. For industrial automationandcontrols, specific updates may not be certified for use and require follow-up with the vendor or verification on a support Website.

53.1.4 Defining the Scope and System Requirements. For M&C sys- tems to operate effectively, management must clearly define the scope and the system requirements.

The scope specifically refers to the relevant processes and the people who interact with the computing environment. For example, to monitor the research and development (R&D) department for network communications regarding intellectual property, the scope may include IT/IS support staff, shared network resources, and existing processes to communicate with remote sites and external departments.

The system requirements refer to the capabilities necessary to perform the desired functions of M&C. In working through the requirements, it is important to remember that prevention mechanisms and controls in real-world environments can eventually fail or become obsolete due to technological changes. The requirements for monitoring R&D may include the need for real-time packet captures, an algorithm to identify intellectual property, automated alerts, and a reasonably secured collection device. Installing a network test access port (TAP) on the network uplink and then writing the captured traffic to a data collector for future analysis may seem logical. However, if a site survey identifies the use of undocumented cellular modems, unencrypted wireless hot spots, and personal email accounts for sensitive communications, the network TAP will fail to address the original goal. In this case, the M&C requirements expand to include signal limiters (Faraday caging), mandatory device restrictions, network access control (NAC), enforced IPSec communication policies, and Web filters. Periodic security awareness training and a policy refresh may also be necessary to ensure the organization clearly communicates expectations on the use of personal email and other electronic communications and devices.

We also need to take into consideration the capabilities of the M&C system, in- cluding the unintended consequences of unnecessary features and capabilities on a

Bosworth, S., Kabay, M. E., & Whyne, E. (Eds.). (2014). Computer security handbook, set. Retrieved from http://ebookcentral.proquest.com Created from apus on 2018-03-19 16:25:53.

C o p yr

ig h t ©

2 0 1 4 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

53 · 6 MONITORING AND CONTROL SYSTEMS

deployed system. For example, a PC-based system used to manage a physical security badge system could also be used by an operator to attach USB devices, play video games, and connect to the Internet for peer-to-peer (P2P) file sharing. These issues can be partially mitigated through system security hardening, agent-based tools, and network design. Distribution panels connected to badge readers perform more specific, restrictive processing functions than a PC or commodity server; for panels, the attention would be directed toward physical access to the devices and communication path.

Compliance requirements and an organization’s security program influence the im- plementation of M&C systems. Regulations may require access controls to restrict information to authorized users and sufficient monitoring to detect unauthorized at- tempts to gain access to information resources. In response to HIPAA, an organization may need to integrate additional log review procedures as well as appropriate mea- sures to control all systems and processes that touch or potentially transfer personally identifiable information (PII). A public company needs adequate controls, to ensure accurate financial reporting. A security policy may reference the need to comply with Sarbanes-Oxley Section 404. The scope of an M&C system would then need to in- clude computing resources, information process flows, and personnel with access to the financial information system. M&C systems should reflect the expectations of an organization’s security policy and should fit into a relevant framework, such as COBIT. Utilizing a control framework provides logical management of M&C systems. The framework enables management to further understand enterprise processes and deter- mine the need for risk mitigation or acceptance. PO9.7 in COBIT identifies control systems as part of the safeguard selection portion of risk management.

53.2 SYSTEM MODELS

53.2.1 Internal, One-to-One, One-to-Many, and Distributed. M&C systems fit into four general models: internal, one-to-one, one-to-many, and distributed. The type of model used depends on the complexity of the system and the type of information required. These models may include autonomous systems as well as those that require human interaction.

1. An internal system is one of the simplest forms of M&C; it monitors or controls itself. A single server or network device may monitor processor utilization or other system components to evaluate system performance issues. From a control perspective, an internal system may prohibit specific actions, such as unauthorized attempts to modify system files or to log on locally to the system.

2. The one-to-one model enables one system to monitor or control another inde- pendent system. When scaled out across a large environment, this model can become cumbersome and result in unnecessary duplication of IT services and processing. For example, an enterprise job scheduler monitoring a single financial application server can identify when files are available for processing. If other systems within the same environment are operating independent job schedulers, operators will require additional time to monitor and troubleshoot the dupli- cate functions. However, the one-to-one model can be quite useful in specific, high-availability situations that require failover. A network firewall, or critical server, would continually monitor and mirror the configuration and session in- formation of the primary system. Once the primary system faults, the monitoring system would assume production functions, to avoid significant disruptions to the business environment.

Bosworth, S., Kabay, M. E., & Whyne, E. (Eds.). (2014). Computer security handbook, set. Retrieved from http://ebookcentral.proquest.com Created from apus on 2018-03-19 16:25:53.

C o p yr

ig h t ©

2 0 1 4 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

SYSTEM MODELS 53 · 7

3. The one-to-many model is most common in enterprise environments. A central monitor and control system remotely manages a number of systems. From a central point, all targets may be interrogated and updated, without the need for manual, one-to-one changes. Centralized M&C can also reduce cost by simpli- fying M&C functions of multiple resources at various sites. This model also improves audit efficiency, as fewer sources of information must be reviewed to validate controls and changes within an environment.

4. The distributed model involves sensors and controls dispersed throughout the environment. The control elements may operate independently or remotely with input from a central control system. Nodes may serve as a local proxy or feed information directly to a central collector for secure log management, reporting, and data reduction. For organizations attempting to manage heterogeneous de- vices, a distributed model enables staff to implement the best M&C components for specific systems while still maintaining the ability to aggregate data into a centralized repository. This level of aggregation provides a wider view of change in the infrastructure.

53.2.2 Automation and the Human–Machine Interface. Automation enables M&C systems to collect sensory information and to initiate a response without the need for human interaction. Many information systems operate round the clock and generate large volumes of event logs. Delegating to operations staff the tasks of manu- ally reviewing millions of log entries and correlating them into meaningful information is impractical. The purpose of M&C systems is to obtain meaningful intelligence from target systems and to report and correct anomalies. By automating data collection and reduction, managers and staff can review consolidated event summaries and respond to situations that have not already been automatically filtered or controlled.

The human–machine interface (HMI) is the point at which an operator communi- cates with a monitoring or control system. In industrial environments, HMI middleware transforms system activities into interactive screens, with enough capabilities for staff to perform specific job functions. The presentation of data is an important factor for HMI. Operators must have the ability to perform their job functions and to maintain adequate situational awareness, without access to unnecessary or distracting system elements. In common network operational environments, interactive Web interfaces serve as the HMI. An analyst may review stoplight coded alerts (red, yellow, green) in a Web interface and perform investigative steps to triage and resolve open issues.

In some situations, organizations leveraging automation may benefit from improved workforce safety and response time. Autonomous vehicles and devices continue to proliferate. The U.S. Department of the Navy utilizes unmanned undersea vehicles (UUVs)7 which reflect the distributed model, performing autonomous actions, with in- formation exchange through a sensor grid within the Global Information Grid (GIG).8

These systems can monitor environmental variables, detect threats such as unexploded ordinance, respond to change, and communicate with system owners. Much like intru- sion detection and prevention systems in a network environment, UUVs can perform functions that may be unsuitable for direct human interaction. Both can perform contin- uous monitoring and collect a large volume of information that could not be collected through manual efforts. Also, similar to intrusion prevention systems in a network environment, a UUV may detect a threat, alert nearby UUVs, and report status back via the GIG.

Bosworth, S., Kabay, M. E., & Whyne, E. (Eds.). (2014). Computer security handbook, set. Retrieved from http://ebookcentral.proquest.com Created from apus on 2018-03-19 16:25:53.

C o p yr

ig h t ©

2 0 1 4 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

53 · 8 MONITORING AND CONTROL SYSTEMS

The expanding use of artificial intelligence (AI) and robotic resources provide additional opportunities for mobile and autonomous M&C. The U.S. Naval Research Laboratory’s humanoid firefighting robot, SAFFiR, is another example of responding to environmental threats without exposing the traditional workforce to hazardous tasks while operating as part of a team. While SAFFiR may not replace a data center’s gas suppression system, artificial intelligence within a data center has been seen in the fight against unsolicited commercial email and spam.

When deploying automated resources, implementing artificial intelligence, or re- motely commanding unmanned vehicles, the integrity of the system and security of the communication paths are critical. Improper physical access, software buffer overflows, weak administrative credentials, and USB malware infections are common ways to compromise the integrity of an M&C system. In network environments, a network engineer may use out-of-band communication paths to connect to the HMI via a con- sole port, in order to avoid common network attacks against a management interface. Using insecure communication methods to update or manage M&C systems across untrusted paths is another common way to expose M&Cs to unauthorized access and compromise. Migrating from FTP, Telnet, and password authentication to Secure Shell (SSHv2) with key pair authentication is one practical way to reduce some of this risk to a more acceptable level.

For network IPSs in a properly baselined network environment, wormlike traffic anomalies may be detected, routed to network tarpits, and cross-reported to additional sensors. In this situation, the automated response is significantly faster and potentially less disruptive than using an intrusion detection system (IDS; monitoring only) with alerts routing to an on-duty analyst for additional follow-up.

53.2.3 Snapshots versus Real Time. Snapshots provide a point-in-time view of a target system. Auditors use these for regularly scheduled audits. Scanning the environment on a monthly basis to confirm compliance can also unearth security trends within an environment. Trend reports identify security performance over time. An organization may notice a sharp decline in vulnerabilities after an external audit. Over time, without a stable vulnerability management program, the number of vulner- abilities will return to preaudit levels. Snapshots do not provide immediate or ongoing information on changes or corrective actions made to production systems. Addition- ally, snapshots will not verify that a control is working all of the time, only during the time that the snapshot was taken. Using monthly snapshots to review a system that frequently changes on a daily basis will not provide the same level of assurance as real-time M&C. Real-time monitoring refers to persistent, ongoing observation of a target. Real-time

control refers to a control system’s ability actively to influence its target. Industrial environments depend on information gathered through real-time M&C. When liquefied natural gas (LNG) travels through an LNG terminal,9 operators should not have to wait until the tanker is empty in order to confirm that any of the product successfully transferred to the storage tanks. An M&C system can continually monitor the volume of product leaving the vessel, compare that data to the volume entering the storage container, trigger alerts if a leak is detected, and initiate a shutoff to avoid product loss.

When allocating and distributing resources to meet demand, real-time monitoring provides overseers with an immediate understanding of the areas of need. In a network environment, this may include peak network usage during an accounting cycle or online shopping trends due to holidays. An Internet-facing shopping portal that uses cloud

Bosworth, S., Kabay, M. E., & Whyne, E. (Eds.). (2014). Computer security handbook, set. Retrieved from http://ebookcentral.proquest.com Created from apus on 2018-03-19 16:25:53.

C o p yr

ig h t ©

2 0 1 4 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

SYSTEM MODELS 53 · 9

computing for resource allocation can use real-time monitoring to transparently detect and provision or deprovision computing and storage resources based on customer demand. Internet sites facing distributed denial of service (DDoS) attacks may use real-time monitoring to identify the incident and real-time control to block or throttle undesirable traffic. A Web-caching service or content delivery network (CDN) may also be leveraged to minimize the impact. In industrial areas, real-time monitoring can detect where electric grid managers should route additional power resources to meet demand, how much to pull from reserves, as well as when to implement real-time controls to enforce rolling blackouts and ensure grid integrity.10

DS13.3 in COBIT 4.1 identifies the need for adequate event logging to analyze activities over time. However, without well-planned automated processes and data reduction, the volume of data generated from snapshots and real-time activities will overwhelm staff. Through centralized data collection and reduction, designated actors can evaluate the results of both real-time and snapshot reporting. This combination can identify general trends, ensure that M&C systems continually operate, and preserve evidence from an identified attack.

53.2.4 Memory Dumps. Memory dumps are representations of the data in memory at a specific point in time. Memory dumps are used most typically after a system failure, but they are also useful in forensic research when investigators want the maximum amount of information possible from the system. There are two approaches to obtaining copies of memory: online, using diagnostic utilities while the system is running, and offline, from magnetic storage media to which memory regions are copied.

53.2.4.1 Diagnostic Utilities. Diagnostic utilities are system software routines that that can be used for debugging purposes. Also known as debug utilities, these programs run at maximum privilege (root or supervisor level, or their equivalents) and allow the privileged user to see or modify any portion of memory. The utilities usually print or display the contents of memory regions in a variety of formats such as binary, octal (base 8), or hexadecimal (base 16), with conversion to ASCII for easier readability. The utilities generally can provide immediate access to memory structures such as terminal buffers that allow the analyst to see what specific users are typing or seeing on their screens, file buffers that contain data in transit to or from specific open files, spoolers (print buffers), and program-specific regions such as data stacks. Because debug utilities also allow modification of memory regions, they are to be used with the utmost circumspection; for security reasons, it is wise to formulate a policy that no debug utility with root access can be run without having two people present. In high-security operations, the output of debug utilities should be logged to paper files for proof that no unauthorized operations were carried out using these programs. Access to privileged debug programs should be tightly controlled, such as by strict access-control lists or even by encryption using restricted keys.

53.2.4.2 Output to Magnetic Media or Paper. One method of doing a memory dump and follow-up analysis is by copying the data from memory onto magnetic media such as tape, removable disks, or rewriteable DVDs. Although it was once practical to print the entire contents of memory to paper, the explosive growth of memory sizes makes such printing impractical in today’s systems. In 1980, for example, a large multiuser minicomputer might have 1MB (megabyte) of RAM available, resulting in a manageable, half-inch-thick stack of paper. At the time of this

Bosworth, S., Kabay, M. E., & Whyne, E. (Eds.). (2014). Computer security handbook, set. Retrieved from http://ebookcentral.proquest.com Created from apus on 2018-03-19 16:25:53.

C o p yr

ig h t ©

2 0 1 4 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

53 · 10 MONITORING AND CONTROL SYSTEMS

writing, it is more common to see business systems with 64-bit processors and over 4 GB (4,000 MB) of memory. For perspective, a relatively older PC with only 256 MB of memory would generate a single printout that could be several feet thick.

Copying memory to a static storage medium is, therefore, preferred for future analysis of memory dumps following system crashes, unknown malware infections, and incidents requiring forensic response.

53.2.4.3 Navigating the Dump Using Exploratory Utilities. On pro- duction systems using reliable operating systems, crashes are rare and generally ex- plored thoroughly to identify the causes of the anomaly. Generally after creating a dump it is necessary to study it looking for the problem and then correcting it. For large-memory systems, exploratory utilities are used to speed the search for problems in the dump by allowing the analyst to find any named system table or other memory region. At a forensic level, hashing may also be used to filter for known-good and known-bad elements within the memory archive.

53.2.4.4 Understanding System Tables. System tables are directories of system data where each datum is identified by an assigned label, by its position in the table, or by pointers from other tables. An understanding of system tables is essential in analyzing system problems.

Regardless of the details of the operating system and the system-specific names of tables, some of the important system tables include:

� Process control table. Pointers to the process tables for each process that is running on the system or that was running when the copy of memory was obtained

� Process tables. Detailed information about each process, with pointers to all the tables for that particular process

� Data stacks. All the variables used by specific processes � Buffers. Data in transit to or from files and devices, such as disks and terminals � Memory management tables. Lists of available memory blocks � Inter-process communications tables. For example, information about resources locking or any logical flags used by multiple processes

Working with someone who understands the detailed structure of the operating system tables can be critically important for security work in which investigators must determine exactly what happened during an intrusion or other unauthorized use of a system.

53.2.4.5 Security Considerations for Dump Data. Memory dumps must be secured while in use and destroyed when appropriate. The dump contains the totality of a system’s information in memory, including such data as:

� Passwords that had just been typed into terminal buffers for use in changing logons or for accessing restricted subsystems and applications

� Encryption keys � Confidential data obtained from restricted files and not authorized for visualization by operations staff (e.g., medical data from personnel files)

Bosworth, S., Kabay, M. E., & Whyne, E. (Eds.). (2014). Computer security handbook, set. Retrieved from http://ebookcentral.proquest.com Created from apus on 2018-03-19 16:25:53.

C o p yr

ig h t ©

2 0 1 4 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

LOG MANAGEMENT 53 · 11

� Financial data that could be used in frauds � National security information restricted to higher levels of clearance than the system administration

53.3 LOG MANAGEMENT

53.3.1 Log Generation. A log file contains a record of events. This record is the basic building block for M&C systems. These files serve as a digital audit trail for system activities. Operating systems, databases, and applications may contain built-in logging capabilities. However, logging is not always enabled or configured for use and aggregation. The system monitors activities and writes relevant information as a log file entry. Operating system log files track application issues, access attempts, and system- wide problems. Thresholds and file sizes can be adjusted to meet the requirements of the environment. It may be unnecessary to write a log entry every time a user successfully opens or closes a file on a network share hosted on a storage volume, but it may be necessary to log and report on privileged access attempts to a management console or remote connections via Secure Shell (SSH). Transactionlogs take logging one step further, by storing copies of the actual changes

made to a system. They have a fixed size, automatically generating a new file for future transactions. Most common in databases, transaction logs can be used to rebuild a corrupt database. Using a known-good database backup and the transaction logs from the database backup to the present time, databases can be rolled forward to a reliable point in time prior to the failure. Transaction logs should be actively monitored, as they can quickly consume large amounts of storage. Normally, committed transaction logs are purged after a successful backup. Other log types, such as Website traffic, may automatically generate new log files once per day; these logs may not contain entire Website transactions, but they will identify the visitor based on predefined criteria. The key here is the flexibility in determining what will be monitored and what format will work best for log generation.

Data retention policies must clearly define how long data should be retained, ac- cording to external requirements and internally driven policy. Retention requirements could range from 1 to 6 years, while some data may need to be retained indefinitely on backup media due to a legal hold. Log file archiving and storage become problematic over time: system-level log files may reach maximum size and overwrite existing log data or trigger a system shutdown; centralized log management systems may slow to a crawl when querying a relational database for data to export to a flat file. Log col- lection and analysis systems must be scalable as event rates and volumes may increase or burst over time. Some organizations address these variances through incorporation of cloud-based logging and storage services, while others rely on more traditional, internal storage solutions.

53.3.2 Types of Log File Records. A log file (also known as an audit trail) traditionally contains records about transactions that have updated online files or other- wise represent events of interest (e.g., logging on to the system or initiating a process). Some database or application log files also may contain copies of records that were affected before or after the logged transaction. There are a number of different types of log file records and each contains a specific kind of information. Typically, all of the operating system log records are stored in files with a maximum configured size, and that are identified by monotonically increasing file numbers. When the file fills up, the

Bosworth, S., Kabay, M. E., & Whyne, E. (Eds.). (2014). Computer security handbook, set. Retrieved from http://ebookcentral.proquest.com Created from apus on 2018-03-19 16:25:53.

C o p yr

ig h t ©

2 0 1 4 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

53 · 12 MONITORING AND CONTROL SYSTEMS

operating system opens another one with the next number in sequence as its identifier. Because log file records of different types have different sizes, on some operating systems the log file is defined with a variable record length.

53.3.2.1 System Boot. The system boot log record contains information on booting up, or starting, the machine. Since this is related to a specific activity and generally to a specific area of the hardware or media, information on the boot can prove helpful when the boot fails and analysis needs to take place.

53.3.2.2 System Shutdown. The system shutdown log record contains in- formation on when the system was shut down and by whom. This information can be invaluable when attempting to analyze a problem or find a saboteur. On systems that include emergency shutdowns (e.g., by calling routines such as suddendeath when system parameters fall outside the range of allowable values), the shutdown record may contain specific information about the cause of the emergency shutdown.

From a security standpoint, trustworthy system boot and system shutdown records can prevent a malefactor from concealing a shutdown followed by unauthorized boot to a diagnostic subsystem that would allow file manipulations without log records to track the operations. The boot records would show an unexplained gap between shutdown and boot.

53.3.2.3 Process Initiation. A process begins when a specific program is loaded and run by a particular user at a particular time. Log records for process initiation show when the various processes were initiated and who initiated them. These files provide a method of tracking employee activity as well as monitoring events that occur. In addition, such records allow cost recovery using chargeback at different rates for different programs or for program launches at different times of day. More important, the record of which programs were executed by whom at which times can be invaluable in forensic research.

53.3.2.4 Process Termination. When reviewing the process termination log record, an administrator will be able to tell when each process completed or was terminated for some other reason. Some systems may provide more information, such as why an unscheduled or abrupt termination occurred, but not all process termination log records provide that information. Process termination records typically include valuable statistical information such as:

� Which process spawned or forked the process in question � Identification of any processes spawned by the processes � Number of milliseconds of CPU used � Number of files opened and closed by the process � Total number of input/output (I/O) operations completed by the process � Total size of the memory partitions allocated to the process � Maximum size of the data stack � Number and maximum size of extra data segments in memory � How many swaps to virtual memory were needed during the existence of the process

� Maximum priority assigned to the process for scheduling by the task manager

Bosworth, S., Kabay, M. E., & Whyne, E. (Eds.). (2014). Computer security handbook, set. Retrieved from http://ebookcentral.proquest.com Created from apus on 2018-03-19 16:25:53.

C o p yr

ig h t ©

2 0 1 4 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

LOG MANAGEMENT 53 · 13

53.3.2.5 Session Initiation. A session consists of the communications be- tween a particular user and a particular server during a particular time period. Whenever a user logs on to a system and initiates a session, a record of that event can be found in the session initiation log record. Frequent review of these records provides important information to alert administrators that an intruder is in the system. For instance, if an administrator knows that an authorized user is on vacation and the session initiation log file shows that a session was initiated for that particular user’s ID, chances are significant that an unauthorized party used the system via a borrowed or stolen user ID. These records are particularly valuable during forensic work.

53.3.2.6 Session Termination. When a session terminates, for whatever rea- son, a copy of the time when it terminated is generally stored in the session termination log record. Much like the process termination record, the session termination record can include a great deal of aggregated information about the activities carried out dur- ing the session, such as total I/O, total number of processes launched and terminated, total number of files opened and closed, and so forth.

53.3.2.7 Invalid Logon Attempts. The invalid logon attempt file can prove invaluable in cases where logon attempts do not succeed. In some instances, the file can tell if the user attempted to log on with an incorrect password, if the user exceeded the allowed number of failed attempts, or if the user was attempting to log on at a seemingly unusual time. These log records can provide important information in cases where an administrator is attempting to track specific actions to a user or to ascertain if the logon failure was due to a simple error or to an attempted impersonation by an unwanted outsider. In hardwired networks, where every device has a unique identifier, the records usually include a specific identifier that allows administrators to track down the physical device used for the attempted logons.

53.3.2.8 File Open. The file open log record provides information on when each specific file was opened and by which process; in addition, the record generally records the mode in which the file was opened: for example, exclusive read and write, exclusive read, exclusive write with concurrent read, append only, or concurrent read and write.

53.3.2.9 File Close. The file close log record provides an administrator with information regarding when the file was closed, by which process, and by what means. The file usually captures information on whether the user specifically closed the file or whether some other type of interruption occurred. The records usually include details of total read and write operations, including how many physical blocks were transferred to accomplish the total number of logical I/O operations.

53.3.2.10 Invalid File Access Attempts. An important log record in the M&C effort, the invalid file access attempt shows the administrator when and to which files there were invalid file access attempts. The records generally show which process attempted the I/O and why it was refused by the file system (e.g., attempted write to a file opened for read-only access, violation of access control list, or violation of file-access barriers).

53.3.2.11 File I/O. Whenever information is placed into, read out of, or deleted from a file (input/output), the information regarding those changes is captured in the

Bosworth, S., Kabay, M. E., & Whyne, E. (Eds.). (2014). Computer security handbook, set. Retrieved from http://ebookcentral.proquest.com Created from apus on 2018-03-19 16:25:53.

C o p yr

ig h t ©

2 0 1 4 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

53 · 14 MONITORING AND CONTROL SYSTEMS

file I/O log. As mentioned earlier, the log includes images of a record before and after it was accessed. The I/O log can be used in file recovery after system or application crashes. Coupled with transaction-initiation and termination records, such data can be used for automatic roll-back or roll-forward recovery systems.

The activities recorded here can prove especially helpful when trying to validate actions that were taken and to attribute them to specific individuals. Detailed logs are typical for databases, where a subsystem provides optional logging of all I/O. Application log records, designed and programmed by application developers, also typically allow administrators to enable such detailed logging.

53.3.2.12 System Console Activity. The system console activity file pro- vides information on any actions that originate from or are viewed at the system console. Typically, the system console includes not only logon and logoff records but also special requests, such as printer form mounts, specific tape or cartridge mounts, comments sent to the console by batch jobs, and free-form communications from users. The console file records all such activity as well as every command from the system operator, and the system responses to those commands. These records provide an excellent tool for investigators tracking down the specific events in a computer incident.

53.3.2.13 Network Activity. Network activity files provide valuable infor- mation on activity taking place on the network. Depending on the sophistication and settings of the system an administrator is using, the information derived can be plenti- ful or scant. Specific devices may generate their own records on network activity; for example, routers, gateways, and firewalls may all keep their own log files. However, typically these are circular files in which records to be entered after the file is full are shifted to the start of the file, where they overwrite the oldest records. In forensic work, it is essential to capture such data before the information of interest is obliterated. Unfortunately, in many systems, the volume of network activity is so high that log files contain only the most recent minutes of traffic.

53.3.2.14 Resource Utilization. A review of the resource utilization log records will show all of the system’s resources and the level of utilization for each. By monitoring this file, administrators frequently make important decisions regarding modifying system configuration or expanding the system.

53.3.2.15 Central Processing Unit. The CPU file shows the capacity and usage of the central processing unit for whichever system is being used and monitored. Based on this information, administrators can monitor when usage is heaviest and the CPU is most stressed, and can decide on utilization rules and requirements as well as on possible CPU upgrades. As in all log file analyses, any outliers (unusual values) and any unexpected change in usage can be investigated. Global CPU utilization records can be compared with the sum of CPU usage collected from process termination records; discrepancies may indicate stealth operation of unauthorized processes, such as malicious software.

53.3.2.16 Disk Space. The log records for disk space show the amount of disk space originally available on a system, the amount of disk space used (and generally what type of files it is being used for), and the amount of disk space that remains free and available. Comparison of total disk space utilization with the total space allocated

Bosworth, S., Kabay, M. E., & Whyne, E. (Eds.). (2014). Computer security handbook, set. Retrieved from http://ebookcentral.proquest.com Created from apus on 2018-03-19 16:25:53.

C o p yr

ig h t ©

2 0 1 4 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

LOG MANAGEMENT 53 · 15

to all files can reveal problems such as lost disk space (i.e., space allocated to files that were never closed properly; such space is unusable by the file system because there are no pointers indicating that the disk sectors are actually supposed to be free). Such unallocated sectors or clusters also may be where malefactors hide data they have stored without authorization by bypassing the file system.

53.3.2.17 Memory Consumption. Important information on the amount of memory in a system and the amount actually being used can be obtained from the memory consumption log records. Such records typically also include information on virtual memory usage. Therefore, they can provide warning of thrashing conditions, where memory segments are being copied to disk and read back from disk too often. Details of memory consumption may be useful in tracking down unauthorized processes such as worms.

53.3.2.18 System Level versus Job Level. Different levels of monitoring, logging, and auditing may take place. Some of this may be preprogrammed, but in most environments it is possible to select the log records and related reports that are desired. For instance, a regular system level audit log may be produced at intervals, just to provide information that the system is up and running without any extraordinary problems. But an in-depth job level audit may take place more frequently in order to monitor the specific job and ensure that it is running correctly and providing the information needed.

53.3.3 Automation and Resource Allocation. Utilizing secure, well- organized log management systems to monitor and respond to events can lower the administrative effort required to manage an infrastructure. With the growing demands of compliance and costs associated with data retention, it is important to include log management within the scope of the enterprise data retention policy. E-discovery laws and postmortem attack analysis rely on efficient access to accurate log infor- mation. Logs require system resources, ranging from media storage to CPU cycles and memory utilization. Trade-offs must be considered when setting aside potential business-generating resources for the purpose of logging and reporting.

Manually reviewing millions of log files on various systems, in different time zones, and inconsistent formats is unrealistic for staff. For geographically dispersed sites, real-time log transfers may be delayed due to limited bandwidth over slow links. Not all logged information is of equal value. Some data records may tie directly to compliance issues, while others provide noncritical benefits to daily operations. Based on policy, management must determine what types of data must be aggregated and reduced in order to monitor and to ensure ongoing compliance. This is part of the scope definition process of M&C systems. Planners and implementers must not only scope current requirements but must ensure that the log management plan will scale to address perceived resource demands for operational, security, and compliance requirements.

53.3.4 Log Record Security. An organization must protect its log records from unauthorized access and modification. The four most common methods of log record security are: access control lists, checksums, encryption, and digital signatures. Combining these methods, based on the system requirements, can adequately protect most log data. Attackers with unfettered access to unencrypted email log files could download copies of the files and search them for sensitive information as well as

Bosworth, S., Kabay, M. E., & Whyne, E. (Eds.). (2014). Computer security handbook, set. Retrieved from http://ebookcentral.proquest.com Created from apus on 2018-03-19 16:25:53.

C o p yr

ig h t ©

2 0 1 4 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

53 · 16 MONITORING AND CONTROL SYSTEMS

modify or delete message content directly from the target server. This type of attack threatens every element of the Parkerian hexad.11 In addition to the common concerns of confidentiality breaches and loss of data integrity, unauthorized access to log files may provide an attacker with additional information on the network environment. Vulnerability scanners may run at scheduled intervals and log detected issues to a central database. Leveraging aggregated data, an attacker can more efficiently compromise a network environment and evade detection routines accustomed to high-footprint reconnaissance.

Operating system and application-level access control lists (ACLs) restrict access to files. Some log files may be written to write-once, ready-many (WORM) media for auditors or legal staff. Operations staff may have no legitimate need to access such data. However, they may need to ensure that the communication flow operates continually. Databases can implement even more granular controls on specific records and fields, to avoid unnecessary information disclosure. Physical access controls to the media while in storage or in transit must also be considered when planning an M&C system for log data. Properly implemented ACLs can limit the level of log data exposure to authorized personnel and system processes.

Organizations subject to PCI DSS are required to implement integrity controls on log data. Historically, 32-bit cyclic redundancy checks (CRCs) generated checksums to guard against file alteration. Today, stronger cryptographic checksums, such as those generated by the SHA-2 family, provide a more reasonable level of assurance.12 Check- sums do not require constant human interaction. For tamper protection, a monitoring system may baseline a system and store copies of files or their hash equivalents for periodic or real-time file comparison. Changes to logs or other critical files could then be centrally reported for manual investigation. A control system could automatically quarantine the unauthorized file and restore a copy of the original file.

Digital signatures use public key cryptography to provide data integrity and non- repudiation. These build on standard cryptographic checksums because they not only confirm file integrity but also identify who or what entity is providing that assurance. For organizations that must submit reports to external recipients, such as government offices, digital signatures can decrease the paper trail and provide a more efficient, digital means of meeting regulatory requirements.

Encryption must be considered for log data in transit and at rest. Encrypting entire log files reduces the ability to view or alter the contents. It also increases the resource usage on the target system during the encryption process. Like checksums, the keys required for decryption should be stored in a secure location, to increase the difficulty in defeating the control. Utilizing whole-disk encryption and then transferring a log file over a network in plaintext is not a consistent method of log security. Establishing secure network links, such as implementing IPSec, provides end-to-end link security. A combination of network and system-level encryption may be necessary to secure log files and other sensitive information properly.

The chain of custody should also be considered when planning a log management system. Some log data may need to be used in court. Without a verifiable audit trail, the contents may be inadmissible. A documented chain of custody for media transfers between staff and sites can validate physical controls. Implementing cipher block chaining (CBC) can further protect against unauthorized changes to log data. The previous log file ciphertext would Exclusive-Or (XOR) with the current plaintext to create a new value for encryption operations. This concept can also be useful for record sets within log files and database applications, as it will identify record deletions and

Bosworth, S., Kabay, M. E., & Whyne, E. (Eds.). (2014). Computer security handbook, set. Retrieved from http://ebookcentral.proquest.com Created from apus on 2018-03-19 16:25:53.

C o p yr

ig h t ©

2 0 1 4 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

GENERAL LOGGING CLASSES 53 · 17

other data modifications. See Chapter 7 in this Handbook for more information on cryptography.

53.4 GENERAL LOGGING CLASSES

53.4.1 Overview. M&C activities vary, based on the business scope, objectives, and target system functions. Targets can be grouped into general classes including: pro- cess flow, job scheduling, network connectivity, environmental measurement, system state assurance, system component status, process activities, configuration settings, file system information, and access control. Current regulations may include only a subset of an organization’s information systems in the scope of compliance. Changes to the infrastructure and compliance requirements are inevitable. It is important to implement scalable and flexible M&C in order to accommodate future needs.

53.4.2 Process Flow and Job Scheduling. Some organizations use a com- bination of mainframe and distributed system resources. The mainframe group may use a particular batch job scheduler to process and monitor job status and output. Other distributed systems throughout the organization might use their own schedulers and logging capabilities. The complexity of this design, however, does not facilitate enterprise-wide monitoring and auditing. A centralized job scheduler may be necessary to monitor and control job flow. The centralized system will need to connect to disparate systems to collect job status and initiate commands. For management, an enterprise view of job scheduling can identify unnecessary complexity and redundancy, leading to future process improvement. When shifting to a central job scheduling system, it may seem desirable to shift the entire environment immediately or possibly to revert to a central mainframe. However, a gradual migration to centralized M&C would be a more ideal method of change.

53.4.3 Network Connectivity. Network connectivity refers to the devices, protocols, and communication media (wired or wireless) used in a computing environ- ment. A network operations center will want to monitor the status of network links, health indicators of critical devices, and data streams traversing the network. In a layered environment, physical access to the network cabling may be secured in cable raceways and network closets or at distribution points. Devices will be up to date and configured according to best practices. Unnecessary protocols will be controlled by blocking or routing suspicious traffic to network black holes and honeynets for further analysis. Network intrusion prevention systems (IPSs) can identify a communications anomaly, block the communication exchange, log the event, and trigger an admin- istrative alert. Prevention requires planning and sufficient controls to deny an attack from achieving its goal. A method to implement M&C for sensitive network nodes may involve moving nodes to isolated segments, deploying in-line network IPSs, and utilizing host-based security agents. Additional enterprise security assessment tools may also scan, report, generate tickets, propose remediation measures, and analyze security trends over time.

In addition to monitoring general network connectivity, some networks are specifi- cally deployed for the purpose of M&C. Legacy industrial systems now integrate com- mon Ethernet networking elements into mechanical, electromechanical, and electronic environments. Wireless M&C options are also available. The ZigBee13 specification utilizes the IEEE 802.15.4 standard to provide ad hoc local networking connectivity.

Bosworth, S., Kabay, M. E., & Whyne, E. (Eds.). (2014). Computer security handbook, set. Retrieved from http://ebookcentral.proquest.com Created from apus on 2018-03-19 16:25:53.

C o p yr

ig h t ©

2 0 1 4 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

53 · 18 MONITORING AND CONTROL SYSTEMS

ZigBee is primarily used for M&C. In a plant floor or outdoor facility, additional ca- bling for M&C systems may be infeasible. A potential solution may be to integrate inexpensive, robust ZigBee control points. For geographically dispersed sites, high- bandwidth, secure connection services such as satellite, leased-line, and virtual private (VPN) network connections bring sites together to manage M&C data centrally.

53.4.4 Environmental Concerns. Some environmental variables are easier to monitor than control. Whether we are using ZigBee to transmit sensory information or a software package to measure AC voltage irregularities, environmental measures provide additional situational awareness for information systems and staff. Humidity, temperature, smoke, and leaking water directly impact computing systems in a data center. Dedicated air-conditioning units and dehumidifiers can monitor and control humidity and temperature. Indeterminate sources of smoke or water leakage may be difficult to control with automated response, but monitoring and alert notification may trigger corrective procedures by staff in order to mitigate risk.

Environmental factors may also impact the quality of an organization’s products. M&C systems can enhance an organization’s quality control efforts, ensuring consistent product manufacturing within predefined tolerances.

As part of a business-continuity plan, it may become necessary for an organization to monitor and prepare for environmental threats such as floods, structural collapse, and power loss. A monitoring system, with early warning capability, could notify staff to report to an alternate work site or to prepare for contingency operations. In the event that an environmental threat disrupts control systems, staff must be capable of manual override. The EPA recommends familiarity with manual operations, in the event of a supervisory control and data acquisition (SCADA) system failure.14 In addition to manual override, integrating redundant M&C systems with seamless failover can decrease the likelihood of operational disruptions.

53.4.5 System State. The system state refers to a collection of critical variables on the target system. A monitoring system may need to track running processes in memory, services, open port connections, system files, hardware status, and log data. In industrial control systems, the system state may reflect the overall picture of an electrical grid, or it may reduce to whether or not a set of valves are open or closed. When an antivirus application process fails to start, resulting in a subsequent malware infection, the monitoring system can trigger an alert so that staff or an automated control system can isolate the infection. One method of monitoring the system state is to run an agent on the host system. Software agents monitor a predefined list of items and report status on a regular basis to a central monitoring hub. When the agent fails to respond or “check in,” the monitoring system can issue an alert to investigate the issue.

Host intrusion prevention systems (HIPS) protect the system state of nodes in a net- work environment. HIPS analyze activities based on signature and heuristic detection routines. They provide a reasonable means of Monitoring and Control (M&C), with the potential for centralized reporting and attack correlation. For postmortem analysis, memory dumps can be useful in analyzing problems with the system state. If a network monitoring system detected botnet-related activity originating from a system in human resources, capturing the live system state may be advantageous to an investigation. As part of the evidence collection process of forensics, controlling and preserving the system state requires specialized training and tools.15

Bosworth, S., Kabay, M. E., & Whyne, E. (Eds.). (2014). Computer security handbook, set. Retrieved from http://ebookcentral.proquest.com Created from apus on 2018-03-19 16:25:53.

C o p yr

ig h t ©

2 0 1 4 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

GENERAL LOGGING CLASSES 53 · 19

53.4.6 System Components. Monitoring applications can track the usage and overall performance of system components, including CPU, memory, and storage media. Operating systems also have built-in tools to monitor components and store results in log files. Inventory management systems collect component-level information as well as software information as configured by operations staff. Six months after an equipment refresh, an audit may identify systems operating with only half of the originally purchased memory. The logged information will help to determine the scope of the issue.

Monitoring the performance of system components can also identify changes in business need or system abuse. With the deployment of a new Web portal, existing Web proxy servers may no longer be capable of handling the heavier load. Logged performance data would corroborate the need to expand the infrastructure or add additional capacity to existing systems. Performance set points trigger alerts when components depart from normal operating levels. The alerts may identify externally driven changes, such as voltage drops, or internal limits, such as maximum memory utilization. Heavy resource utilization on a historically idle PC running HMI may even point to misuse of the system for non-SCADA-related activities, such as internal network scanning, password cracking tools, or gaming.

System component monitors most often attempt to identify overutilized CPUs, heavy memory consumption, and full storage media. However, identifying routinely under- utilized resources gives management the ability to reallocate resources to areas of need rather than purchase unnecessary additions to the infrastructure. Disk quotas control the allowable amount of usable media for users and applications. To protect a system from unintentional or malicious overutilization, quotas should be reviewed as part of a layered strategy. Virtual machines use storage, memory, and processor quotas to con- trol the resources utilized on a host system. With large virtualization environments, an enterprise virtual manager system may be necessary to ensure adequate load balancing across all of the virtual system hosts as well as to determine if additional tuning is required to improve virtual machine performance.

53.4.7 Process Activities. A process refers to a running program in a comput- ing device. Processes may initiate at the system or user level and may contain multiple threads. M&C processes can prevent malware infections and identify abnormal pro- cess activities. Antivirus systems typically address this area. The SQL Slammer worm targeted a vulnerable process over a network connection, injecting code into memory without writing to disk storage.16 In addition to process monitoring, network traffic analysis and network IPSs could mitigate this type of activity. Using enterprise moni- toring tools to aggregate critical process information on a number of systems will help to identify application issues, such as runaway processes. For performance tuning and resource evaluation, agents can also monitor the CPU time of running programs for high utilization.

Monitoring process activities can also play a role in software metering and reporting. Organizations may want to identify application usage for different departments, in order to avoid deploying unnecessary applications and paying licensing fees for shelfware. Agents can centrally report elapsed time for target processes, for data aggregation, and for management report generation. Monitoring the use of specific types of software utilities, such as those used primarily by administrative and security personnel (e.g., nmap, tcpdump, hping, Wireshark, and Microsoft SysInternals), could also indicate unauthorized network reconnaissance. Blocking the execution of known applications

Bosworth, S., Kabay, M. E., & Whyne, E. (Eds.). (2014). Computer security handbook, set. Retrieved from http://ebookcentral.proquest.com Created from apus on 2018-03-19 16:25:53.

C o p yr

ig h t ©

2 0 1 4 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

53 · 20 MONITORING AND CONTROL SYSTEMS

by file name or hash value can limit the level of follow-up required to locate and kill remote processes. Monitoring for uncategorized or unapproved processes may further help in identifying the cause of performance degradation on remote systems.

53.4.8 File System. File system activities provide a wealth of auditing infor- mation. File systems store log data ranging from application errors to unauthorized authentication attempts. Just like IDS logging, file system logging requires perfor- mance tuning to aggregate the data and to avoid data loss. Logging every file access attempt and data modification on a system will fill up event logs with generally useless information. If system owners configure the log file to overwrite when full, actual critical events may be lost. The volume of log entries also impacts network resources. A constant flow of file system activity logs may negatively impact the performance of the log collector. Focusing on critical system files, sensitive data, and configuration settings will decrease the number of log entries and provide a more targeted set of results.

The configuration files for operating systems and applications require layers of protection to avoid unauthorized modification. Much like the layers discussed in Sec- tion 53.3.4, regarding log-record security, Access Control Lists (ACLs), encryption, digital signatures, and checksums can play a critical role in protecting objects within the file system. Attempts to bypass M&C systems may begin with configuration files and settings. End users attempting to bypass Internet Web filters may reconfigure their Web browsers to use a rogue proxy server. Attackers attempting to modify the configuration of a poorly secured Web server may leverage the security lapses to target additional sys- tems connected to the internal network. Controlling changes to configuration settings via system policies and HIPS will mitigate these kinds of attacks.

53.4.9 Access Controls. Access control is a central part of security manage- ment and compliance efforts. Organizations often rely on more than one stand-alone system for identification and authentication, including applications, network operating systems, and building security. As a result, they face significant challenges when at- tempting to communicate, aggregate, and manage access control events. Adding and removing staff to a secure environment may involve badge identification, security to- kens, and passwords. An M&C system targeting access control will need to ensure that unauthorized personnel do not have access to any physical or digital resources. Management may first need to develop a process flow with support from operations staff and business stakeholders.

Aggregating access logs and detailing failed login attempts and multiple user instances aid in the identification of system abuse. When users log on to network resources, they establish a session with the target system. Multiple sessions for the same user, at multiple sites, may indicate that a user account has been compromised or is being shared. Depending on the level of importance, this information may surface in an exception report, trigger an administrative alert, or result in an automated account lockout. Similarly, a series of invalid login attempts may reach a threshold and automatically disable the user account for a predefined period of time. This control minimizes the effort required to actively monitor system accounts while ensuring that attackers are not able to perform a brute-force attack on the credentials of an authorized user.

See Chapters 28 and 29 in this Handbook for further discussion of identification and authentication.

Bosworth, S., Kabay, M. E., & Whyne, E. (Eds.). (2014). Computer security handbook, set. Retrieved from http://ebookcentral.proquest.com Created from apus on 2018-03-19 16:25:53.

C o p yr

ig h t ©

2 0 1 4 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

DATA AGGREGATION AND REDUCTION 53 · 21

53.5 DATA AGGREGATION AND REDUCTION

53.5.1 Centralized Data Stores. Systems generate logs in a variety of for- mats that are not always easy to access. The first phase in data aggregation is ensuring that logging is working properly on the target system. This may require installation of additional log collection software, in order to push or pull data in a standard syslog format. The second phase, gradually connecting logging points to a centralized data store, builds on individual logging mechanisms to create an enterprise view of events. Centralized data storage provides a single point of analysis and audit, without the time-consuming process of manually interrogating individual systems throughout the environment.

Log data must be communicated in a secure manner. An agent-based system needs to establish a secure communication channel with the primary collector, to avoid distributing log details to an unauthorized collector. It may also be advantageous to prohibit the log aggregator from collecting unsolicited syslog messages. This security measure may be built into the log forwarding or aggregating mechanism, or it may utilize IPSec over controlled network links.

A major problem with large volume data stores is processing time. Log processing can potentially delay or otherwise inhibit incident response. Depending on the resources available, it may be more economically advantageous to store secured log data in compressed archives while using agent-based monitoring only to report critical security issues or operational problems to central storage. The time and effort to log, parse, and report on every data block received by the central collector may exceed internal security-policy requirements and the perceived cost benefit. Filtering out noncritical events and alerts would then be part of the baseline process for the central M&C system. Storing and analyzing entire log files may serve as a secondary (slower) monitoring mechanism, while the security-specific alerts are handled on an immediate basis.

53.5.2 Filtered Queries. The volume of log file records can be overwhelming and generally impossible for operations staff to review individually and on a regular basis. Centrally storing the data does not change the infeasibility of the task. It does, however, lend itself toward improved data reduction. Transforming raw data into a meaningful, reduced form can minimize the noise and enable staff and automated pro- cesses to target higher-priority activities. Running filtered queries against log records can provide more immediate results on potential attacks or system issues. A scheduled query may list all failed logon attempts. Additional filtering may drill down to a set of computing assets (e.g., servers processing credit card data) or user types such as root- level accounts. Another more specific query may only list network traffic anomalies between the R&D department and an array of Internet proxy servers.

53.5.3 Analyzing Log Records. Log records can be valuable to the system administrator,butonlyiftheyareputtouse. Properlyusingalogfilerequiresmonitoring and reviewing its records and then taking actions based on the findings. Such analysis typically uses utilities provided by the supplier of the operating system or by third parties, such as commercial software companies or freeware distributors.

53.5.3.1 Volume Considerations. Someone must make a decision regard- ing how big log files should be. Such a decision is generally made by the system administrator and is based on what is considered useful and manageable. If money is involved—for instance, if additional storage capacity is needed—the chief technology

Bosworth, S., Kabay, M. E., & Whyne, E. (Eds.). (2014). Computer security handbook, set. Retrieved from http://ebookcentral.proquest.com Created from apus on 2018-03-19 16:25:53.

C o p yr

ig h t ©

2 0 1 4 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

53 · 22 MONITORING AND CONTROL SYSTEMS

officer (CTO), chief information officer (CIO), chief operating officer (COO), system auditor, and a variety of other stakeholders might be called on to participate in the decision-making process. However, in the three and a half decades from 1980 to the time of this writing in June 2013, disk-space costs fell about 37 percent per year com- pounded annually—from approximately $853,000 per gigabyte (in 2013 dollars) to approximately $0.04 per gigabyte in constant dollars, so disk space is not much of an issue anymore.17 More important is that log files, like any file, may be left in an inconsistent state if the system crashes; closing a log file and opening a new one in the series is a prophylactic measure that ensures that less information will be lost in disk I/O buffers if there is a system crash. In addition, it is wise to put log files on a separate disk controlled by a separate processor; that way, one can disable write-behind (delayed writes) and force completion of I/O for every record of the log file.

53.5.3.2 Archiving Log Files. Archiving is a very important part of making and using log files. Every organization needs to decide how long to keep its log files and where to keep them. Decisions of this nature sometimes are made based on space considerations but more frequently are made based on legal requirements within specific industries. Some companies may decide to keep materials for a year or two, while others may be mandated by law to retain archived log files for seven or eight years.

The decisions regarding the archiving of log files should never be made arbitrarily; in every instance a careful review and check of company, legal, and industry require- ments should be conducted. Based on the findings of that review, a written policy and procedures should be produced. Every organization needs to tell its employees what these policies and procedures are, so they can be aware of what materials are being kept, where they can be found, and how they can be accessed.

53.5.3.3 Platform-Specific Programs for Log File Analysis. Many op- erating systems are in existence, and although there are certain similarities in how they function, there are also differences. Special training on each specific operating system may be necessary in order to do a correct analysis of the platform-specific log files it generates.

53.5.3.4 Exception Reports. The volume of log file records can be over- whelming. For example, a customer-facing banking portal could generate log entries for logons, logoffs, financial transactions, and other record changes. It may also log attempts to penetrate Web application defenses or detect hijacked banking sessions. Exception reports allow the analyst to focus on specific characteristics (e.g., unusual wire transfer activities to foreign countries). Such tools greatly simplify detection and analysis of anomalies and are particularly helpful in tracking down unauthorized and undesirable activities.

53.6 NOTIFICATIONS AND REPORTING

53.6.1 Alerts. Log management must include layers of automation to reduce the time required to review and respond to events in the environment. How an M&C system deals with alerts will directly impact the security of the target system. Overwhelming operators with too many alerts will result in slower problem-response time as well as the potential to ignore critical issues. The purpose of alerts is to improve responsiveness to major issues, such as a leaking pipeline or multisite network outage. Alerts may be

Bosworth, S., Kabay, M. E., & Whyne, E. (Eds.). (2014). Computer security handbook, set. Retrieved from http://ebookcentral.proquest.com Created from apus on 2018-03-19 16:25:53.

C o p yr

ig h t ©

2 0 1 4 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

NOTIFICATIONS AND REPORTING 53 · 23

configured at specific set points so that a responder will be notified only when the attack threshold is reached. Elements that are controlled in the environment may have a higher threshold for alert notification. A sudden influx of malware from the Internet may be immediately detected and filtered at the network edge. Notifying operations staff of a large volume of malware may be useful. However, spamming security administrators with alerts on every blocked attack would be an inefficient use of alert notification resources.

Additionally, the means of alert notification play an important role in business continuity and disaster recovery. Out-of-band monitoring systems may detect a network equipment error that could not otherwise be detected by the failing device itself. For alert recipients, multiple notification means may be necessary. Email, pager, cell phone, and SMS messaging are the most common forms. Alert visualization is another valuable means for operators actively monitoring the environment. Similar to the dashboard concept, visualization can reduce data collected from sensors into a visual map, with graphical indicators to identify system issues. A combination of dashboard-style alert monitoring and targeted message delivery may provide the best coverage for issues of high importance.

In industrial environments, operators utilize HMI tools to maintain situational aware- ness with field equipment. HMI uses virtual buttons and other visual elements to sim- plify industrial functions. If alerts are frequently generated for noncritical activities, staff will clear the alert list and ignore them over time. Ignoring alerts for critical issues can directly impact production and lead to costly repairs. In this situation, a management dashboard could display performance statistics that may trigger a field investigation into the root cause of declines in production performance.

53.6.2 Trend Analysis and Reporting. Data aggregation, reduction, and correlation lay the foundation for trend analysis. Data related to compliance require- ments can be analyzed to determine the pace of security improvements within the organization. Further analysis may identify the level of consistency of an internal se- curity program as well as the true drivers of audit compliance. If system vulnerabilities and business risk continually peak in between scheduled external audits, management will need to investigate the root cause of this unstable, cyclic behavior. Chargeback refers to the ability to charge for the use of IT services. Some organiza-

tions include these costs in the overhead of doing business rather than billing individuals and departments. Regardless of the financial preference, enabling chargeback moni- toring in an environment provides an understanding of how information resources are used. If the marketing department utilization has grown from 40 to 70 percent of the Internet bandwidth, and the helpdesk use has expanded from 30 to 50 percent of the cloud computing resources, the trends may encourage management to realign resources to meet business demand or investigate resource abuse. Monitoring resource utiliza- tion and demand can also benefit development and testing cycles, so that production resources are properly allocated.

Chargeback systems, such as internal billing services and those used by external service bureaus, prove valuable in monitoring and tracing system activities through their logs. In some states and cities, legislation requires that these types of services keep accurate logs for audit purposes. The original records are used not only for tracking but also in court cases as evidence. In most situations, both internal and external services are the secondary “proof” of transactions, while the initial system logs provide the primary proof.

Bosworth, S., Kabay, M. E., & Whyne, E. (Eds.). (2014). Computer security handbook, set. Retrieved from http://ebookcentral.proquest.com Created from apus on 2018-03-19 16:25:53.

C o p yr

ig h t ©

2 0 1 4 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

53 · 24 MONITORING AND CONTROL SYSTEMS

The log file records provide the basis for sophisticated billing algorithms that en- courage rational use of resources. In addition, because unexpected changes in expenses can stimulate interest by accounting staff and managers, billing systems can sometimes aide in the identification of unauthorized usage, based on historical patterns. Exception reports focus on specific data anomalies, such as employee expense

reports that suddenly exceed US$9,000. Managers may want to employ continuous monitoring of the financial system to evaluate exception report trends. In addition to misuse and fraud, exception reports can identify system problems. Generating excep- tion reports for systems that regularly operate below acceptable performance levels may point to a failing component. Management, at an industrial site that regularly fails to account for missing product, may uncover procedural issues that result in wasted material or defective equipment that must be repaired to resolve the ongoing product loss. Exception reports may also identify an isolated issue or a widespread problem. If change management recorded the replacement of hardware on five pipeline segments and they all started leaking at the same time, aggregated log data and exception reports would support the need for hardware and procedural reviews. Or an exception report, based on sensor data collected in November 2002 along the Denali Fault,18 may cor- relate with an environmental issue (e.g., earthquake) that would possibly explain the cause of an equipment malfunction.

See Chapter 10 in this Handbook for basic information about statistical methods.

53.6.3 Dashboards. Dashboards consolidate information into a relevant and easily understood summary. Text, visual, and auditory elements may be employed, de- pending on management needs and system capability. Dashboards build on Web-based technology with a database backend to present a high-level overview of operational status at near-real-time refresh rates. Charts, graphs, stoplight indicators (red, yellow, green), system visualizations, and alert banners enhance the dashboard experience when used in moderation. Employees typically reference dashboards from a standard Web browser or through large video screens mounted in command centers and common areas.

Department and management-specific dashboards should also be considered when implementing specialty M&C systems. Depending on the sensitivity of the information, rotating the dashboards on common screens or within the Web portal itself may provide an opportunity to increase employee awareness of organization-wide and department- specific performance. Associates may learn more about the current level of business risk, of current operational performance (e.g., system uptime, and product generated, or sales volume), or even of the current state of cybersecurity.19

In addition to dashboards, organizations continue to use a number of system man- agement consoles to monitor and control specific elements within an infrastructure. System management consoles often cater more to technical operations staff than to upper management. System management consoles and dashboards will likely continue to coexist, due to functional needs.

53.7 CHANGE AND SECURITY IMPLICATIONS

53.7.1 Change Management. M&C systems enhance an organization’s abil- ity to identify and manage change in the information infrastructure. Environment isola- tion (Development, Test, & Production), source code control, and separation of duties are fundamental prerequisites for effective change management. Knowing when au- thorized and unauthorized changes occur can improve problem resolution and assist in

Bosworth, S., Kabay, M. E., & Whyne, E. (Eds.). (2014). Computer security handbook, set. Retrieved from http://ebookcentral.proquest.com Created from apus on 2018-03-19 16:25:53.

C o p yr

ig h t ©

2 0 1 4 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

MONITORING AND CONTROL CHALLENGES 53 · 25

incident response. In a data center environment, centralized system monitors track op- erational status. When running configurations are updated on core network equipment, a monitoring system could alert site staff in the event that the changes were not autho- rized. The cause may trace back to the remote exploitation of a known vulnerability or to an unintended change by a network engineer connecting to the production environ- ment instead of a test lab. In either case, the information reported enables management to assess the situation and to implement corrective actions to reduce the likelihood of future attacks or procedural oversights.20

53.7.2 Configuration Protection. When new systems are deployed or legacy systems are brought up to specific compliance levels, configuration concerns surface. Although policy-based standards may correctly define the appropriate configurations to protect the information assets, failure to consistently apply configuration templates or checklists introduces unnecessary complexity to vulnerability and configuration management. To address this challenge, M&C systems can identify anomalies and bring systems back into compliance using predefined criteria. The Payment Card Industry Data Security Standard (PCI DSS) requires file integrity detection and alerting. However, an organization may also find it advantageous to deploy a system that will automatically detect, alert, and correct system integrity discrepancies while reporting on the noncompliant files or settings.

In industrial control systems (ICSs), programmable logic controllers (PLCs) store and run ladder logic programs to control hardware devices in the field. Programmers or automation specialists update these programs using specialized software for indus- trial networks. Modifying the program will directly affect the output of the actuators connected to the PLC. For example, incorrectly modifying a tank sensor’s set point to a value greater than the tank’s capacity could result in product loss, requiring manual override. For that reason, the program must be protected from malicious and acciden- tal alteration. Using a password to protect the running program and layered network defenses such as a network IPS contribute to configuration protection in this scenario.

53.7.3 Performance Considerations. Like all systems, M&C systems re- quire resources to operate. Depending on the operational model, these resources may come from the same host system, a network connection, or a remote device. Failing to gauge the performance impact of a monitoring system could leave the operational environment in a degraded state. Additionally, deploying new systems during heavy loads in a business cycle may disrupt normal operations. Installing an enterprise file integrity monitoring system and performing a baseline on production systems during peak hours could lead to overutilization of system resources and could halt critical production jobs. Changes in M&C require planning and coordination with relevant business units and technical staff, to ensure that new systems meet both the business needs and the technical requirements to operate efficiently.

53.8 MONITORING AND CONTROL CHALLENGES

53.8.1 Overview. Legacy systems do not always possess sufficient M&C for today’s business and regulatory requirements. The art of retrofitting security into a legacy system requires overcoming physical, technical, and psychosocial barriers. Physical barriers range from wired ICS installations to wireless mobile communi- cations. Technical issues include learning to detect and monitor unique communica- tion protocols, understanding the production performance requirements, and managing

Bosworth, S., Kabay, M. E., & Whyne, E. (Eds.). (2014). Computer security handbook, set. Retrieved from http://ebookcentral.proquest.com Created from apus on 2018-03-19 16:25:53.

C o p yr

ig h t ©

2 0 1 4 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

53 · 26 MONITORING AND CONTROL SYSTEMS

systems that historically operated in isolated locations with limited security oversight. Psychosocial challenges are often the most difficult. Organizations and business sectors unaccustomed to mature M&C systems typically deny the need for such systems. Ra- tionalization attempts generally include denial that an attacker would ever target their systems, claims that the business is running well, and concerns that additional changes or complexity will likely disrupt production. Security-awareness training and changes in leadership can partially address these misconceptions while pointing to the lack of M&C data available to support any claims that operations is running as efficiently and securely as it should.

53.8.2 Industrial Control Systems. Industrial control systems (ICSs) oper- ate in a number of industries, including oil, water, and power. ICSs are generally divided into distributed control systems (DCSs) and supervisory control and data acquisition (SCADA) systems. DCSs are more commonly associated with processes such as oil refining. SCADA systems involve more human interaction via HMI, and they collect data from a number of remote devices. Some systems contain elements of both DCS and SCADA. Security issues have increased, due to network connectivity and risks to critical infrastructure. These systems are expected to continue to integrate on a global scale, with improved, centralized data aggregation and reporting. Management will find value not only in aggregating their own organization’s data but in collaborat- ing in industry forums to implement more stable, interoperable, and secure industrial M&C systems. Like mainframes, SCADA systems no longer operate in an isolated environment. Sites often communicate via leased lines, satellite, and dial-up modems. Some industrial sites utilize ZigBee wireless equipment rather than installing standard cabling to monitor and control remote devices. Technicians dial in with a modem or through a virtual private network (VPN) tunnel over the Internet to manage industrial systems remotely. Other direct connections from the Internet (via Remote Desktop or VNC) may also exist but are not recommended.

M&C challenges for these systems include authentication, network security, con- figuration protection, and physical security. Historically, authentication has not been required to use a PC to communicate directly with a PLC over an SCADA network. Some vendors now attempt to build authentication into the HMI. However, the network protocols used in SCADA (e.g., MODBUS/TCP, DNP3) can still send unsolicited mes- sages to the PLC to execute arbitrary commands. Configuration protection is typically associated with the running program on a PLC, which may have a weak or nonexistent password. From the operator standpoint, HMI usually runs on an unpatched PC with application-level security controls. These controls are typically bypassed by attacking the improperly secured operating system or inserting an infected USB drive. Laptops used by engineers to manage and update PLC programs cross legacy air gap bound- aries and are often connected to untrusted external networks, used for Internet and email, and exposed to off-site physical attacks. Physical security remains a challenge, as equipment may not be located in a secured area, or operators may lack adequate security awareness training to implement proper security procedures. Fortunately, these M&C systems may leverage existing information security resources to mitigate risk in a layered architecture. NIST SPEC PUB 800-82 clearly describes the security land- scape surrounding these systems. Network firewalls, intrusion prevention systems, and more robust physical security would all contribute to a more secure SCADA envi- ronment. Vulnerability detection tools now integrate SCADA protocols, with the goal of detecting vulnerabilities and mitigating risk. Continuing to develop more secure

Bosworth, S., Kabay, M. E., & Whyne, E. (Eds.). (2014). Computer security handbook, set. Retrieved from http://ebookcentral.proquest.com Created from apus on 2018-03-19 16:25:53.

C o p yr

ig h t ©

2 0 1 4 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

MONITORING AND CONTROL CHALLENGES 53 · 27

communication protocols, and establishing configuration protection guidelines, would further improve the authentication weaknesses in SCADA deployments.

M&Cs in an ICS environment become more complex due to ownership and respon- sibilities. Traditional IT organizations often support networks up to a network port but often lack the expertise and knowledge specific to industrial control environments. Con- trol engineers may implement specific network elements based on production demands, without necessarily aligning configurations with security and policy requirements.

53.8.3 Mobile Computing. As we continue to integrate mobile and distributed computing systems, the complexity and difficulty required to secure systems increases. We have more variables to address. Information flows even further from the traditional network perimeter. Organizations continue to support bring your own device (BYOD) policies that introduce untrusted and insecure network nodes into the environment; these personal devices storing company data should be addressed through very clearly defined policies and standards. With advances in de-perimeterization, M&C systems must ensure that data remains secure while in transit and at rest, as determined by or- ganizational policy. Mobile technologies communicate over wireless links, invisible to traditional M&C systems. Some wireless devices require centralized system manage- ment but rarely connect to the corporate network. Mobile encryption and mandatory VPN connectivity help to control data storage and transmission. With centralized policies, these systems promote more consistent data communications throughout an organization.

Radio-frequency identification (RFID) monitoring systems wirelessly identify and collect information from the target system. NIST 800-98 describes the technological benefits and risks related to implementing this technology. M&C systems often collect sensitive information. The privacy issues inherent in RFID will require thorough risk assessment to avoid potential data loss. Tagging all of an organization’s employees with RFID badges that contain PII subject to HIPAA regulations would be unwise, as the RFID tags could potentially be accessed from over one meter away without the holder’s knowledge. From an inventory perspective, RFID tags provide a means to automate site audits of company assets or to collect asset information without manually writing it down. To avoid compromise, the device standards use integrity checks (CRC) and require a password to render them nonresponsive.

53.8.4 Virtualization. Organizations use a variety of computing equipment to meet their business needs. Some equipment may remain underutilized, while critical database servers require additional storage space and working memory. Virtualization provides the ability to slice and pool computing resources into more efficient, targeted, and often portable business resources. Virtual systems generally consist of physical hardware, a virtualization interface (VI), and a virtual machine (VM). The VM may be an application or an entire operating system. Since the VI oversees the VMs, we must implement appropriate M&C at the VI layer as well as within and around the VMs.

Users of a virtualized operating system may not be able to detect that it is virtualized. For example, a Web hosting company may wish to provide dedicated virtual servers to its customers without the additional expense of dedicated hardware. In this situation, the organization could deploy FreeBSD servers and implement a degree of virtualization using “jails”21 to provide a high level of compartmentalized, system-level access to customers. An operator with root access to a jailed environment should not see the processes executed by other jails nor the underlying system hosting the jails. However, the host system owner may monitor or control elements of the host system as well as

Bosworth, S., Kabay, M. E., & Whyne, E. (Eds.). (2014). Computer security handbook, set. Retrieved from http://ebookcentral.proquest.com Created from apus on 2018-03-19 16:25:53.

C o p yr

ig h t ©

2 0 1 4 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

53 · 28 MONITORING AND CONTROL SYSTEMS

those within jailed environments. Additional monitoring of the host system may also be necessary, to detect jailbreak attempts.

Another type of virtualization, paravirtualization, utilizes a hypervisor as the VI between the hardware and the VM. Rather than create identical jailed environments, a hypervisor can be used to support more than one type of guest VM, such as Ubuntu, Fedora, and PC-BSD. This configuration is possible because the hypervisor handles all communications (hypercalls) between the hardware and the VMs. Along the same lines as a FreeBSD host with jails, the hypervisor can monitor and control activities within and around the VMs with varying degrees of transparency to the VM user. The capability of stealth VM monitoring makes virtualization a useful monitoring tool for honeypot research. For a greater level of system assurance, organizations will need tools to detect and prevent attacks against the hypervisor.

Portability, an advantage of virtualization, poses a challenge for M&C systems. VMs can migrate from one hardware device to another frequently, while the integrity of an off-line VM is unknown. In a managed, virtualized infrastructure, performance degradation issues detected in the VI may trigger VMs to migrate from one physical server to a less utilized resource. An unstable VM may also be manually forced off line and rapidly redeployed using a backup virtual disk, without disrupting other VMs sharing the same physical hardware. Tracking these moving targets requires reliable access to the virtual pool of resources, documentation mapping virtual to physical resources, as well as a clearly defined policy for virtual system provisioning. For example, an organization with policies that require clear separations between confidential and public systems should prohibit the same hypervisors from managing both payroll applications and public kiosk VMs on the same hosts.

53.8.5 Cloud Computing. Cloud computing uses several deployment and ser- vice models to provision flexible computing and storage resources. However, M&C in the cloud introduces additional challenges, due to the deployment variations and addi- tional parties involved in functional tasks. In public clouds, the physical environment and network infrastructure M&C responsibilities belong to the hosting provider. As a result, organizations have significantly less visibility into daily network operations and incident handling activities, and must rely on third-party attestations and standard reports (e.g., SAS 70, SSAE 16). Decreased M&C visibility places increased reliance on contractual agreements between the cloud provider and the cloud tenant. Guidance published by ENISA and the Cloud Security Alliance can assist in the cost and risk benefit analyses.

In addition to standard computing and storage resource needs, organizations may also leverage cloud resources for log management, disaster recovery, and development environment isolation.

Security responsibilities and M&C capabilities are greater for an organization uti- lizing the infrastructure as a service (Iaas) model than other service models. Virtual system instances can be configured with standard logging capabilities at the operating system and application level. However, some of the hardware elements such as mem- ory may be shared with neighboring cloud tenants. Platform (PaaS) and software as a service (SaaS) models provide customers with less visibility outside the application environment.

Management of cloud resources may be handled through a standard Web interface and APIs. While many of the monitoring and control elements may still exist, the approach to accessing and storing the data may vary. For example, an administrator may create a snapshot of a running instance without impacting the production system. Additionally, the snapshot may be mounted in cloud storage for forensic follow-up.

Bosworth, S., Kabay, M. E., & Whyne, E. (Eds.). (2014). Computer security handbook, set. Retrieved from http://ebookcentral.proquest.com Created from apus on 2018-03-19 16:25:53.

C o p yr

ig h t ©

2 0 1 4 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

SUMMARY 53 · 29

Controlling access to keys, management interfaces, virtual machines, and storage vol- umes are important targets for M&C in the cloud. Additionally, data encryption should also be considered where possible.

53.9 SUMMARY. Monitoring and control systems provide technology stakehold- ers with additional assurance related to system operations. M&Cs enable visibility into production operations and may also detect and prevent undesirable events and oper- ational inefficiency. Controlling every element of an information system is generally impractical from a cost and risk-based standpoint. However, in taking a risk-based ap- proach, we can identify what should be monitored, controlled, or accepted as a residual risk. Regulations, internal policies, industry frameworks, business requirements, and operational needs all contribute to the decision process in selecting and implementing M&C systems and functions.

Defined scope and business requirements drive the selection of an appropriate M&C model. While human interaction continues to play a critical role in legacy systems, increased sophistication in automation can lead to improved reporting capability and continuous assurance. Unique challenges related to automation surface in environments with specific requirements including industrial controls.

Monitoring, control, and auditing interrogate information systems, identify prob- lems, initiate corrective measures, and generate meaningful information on the state of various systems and processes. The systems may involve human interaction or function in an automated, closed-loop format. Systems generate log files based on system activ- ities, store them in secure locations, and enable aggregators to collect and reduce the data into actionable information. Although log aggregation improves the analysis pro- cess, the resources required to store and manipulate the data can become problematic. Not all events are useful. In order to manage reasonable data volumes, only specific activities should be logged or collected by the central management system. Log file data provides a means to analyze events historically at any measured point in time—a necessary part of infrastructure management. Organizations need to understand the value of assets, align business with regulatory requirements, and find new ways to leverage M&C to improve operational performance.

53.9.1 M&C Checklist. M&C systems may be reviewed at any phase of the life- cycle (e.g., planning, implementing, maintaining, and decommissioning). Assessing the appropriateness of M&C systems and components involves multiple actors. Enterprise Architecture may sit down and define the requirements and identify a short list of poten- tial solutions, while Risk Management, Audit, and Information Security provide feed- back based on their areas of focus. In larger environments, Risk Management may also consult with Legal, Senior Management, and IT Governance board members to ensure that M&C investments adequately align with business objectives, maintain acceptable risk levels, and integrate with the evolving maturity and direction of IT services.

Working through an M&C checklist should result in the identification of key el- ements for a current or future M&C implementation. The information may serve as an input to broader functions including risk management, information security, and enterprise planning. At a minimum, an M&C checklist should include:

� Identification of vision and goals for M&Cs � Definition of how M&C will align with business � Mapping of security, compliance, business, and legal requirements � Scope, architecture, M&C model, and deliverables

Bosworth, S., Kabay, M. E., & Whyne, E. (Eds.). (2014). Computer security handbook, set. Retrieved from http://ebookcentral.proquest.com Created from apus on 2018-03-19 16:25:53.

C o p yr

ig h t ©

2 0 1 4 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

53 · 30 MONITORING AND CONTROL SYSTEMS

� Components to be monitored or controlled � Storage methods (store/forward) � Data storage resources and security levels � Data reduction and reporting outputs � Response methods � Self-defending M&C items (e.g., log blackouts/variance as a detective measure)

53.10 FURTHER READING Badger, L., D. Bernstein, R. Bohn, F. de Vaulx, M. Hogan, J. Mao, J. Mesina, K. Mills,

A. Sokol, J. Tong, F. Whiteside, and D. Leaf. U.S. Government Cloud Computing Technology Roadmap Volume I Release 1.0 (Draft) High-Priority Requirements to Further USG Agency Cloud Computing Adoption. NIST Special Publication SP 500-293. www.nist.gov/itl/cloud/upload/SP 500 293 volumeI-2.pdf

Badger, L., R. Bohn, S. Chu, M. Hogan, F. Liu, W. Kaufmann, J. Mao, J. Messina, K. Mills, A. Sokol, J. Tong, F. Whiteside, and D. Leaf. US Government Cloud Com- puting Technology Roadmap, Release 1.0 (Draft), Volume II Useful Information for Cloud Adopters. NIST Special Publication SP 500-293. www.nist.gov/itl/ cloud/upload/SP 500 293 volumeII.pdf

Catteddu, D., and G. Hogben. “Cloud Computing: Benefits, Risks and Recommenda- tions for Information Security.” European Network and Information Security Agency (ENISA). November 20, 2009. www.enisa.europa.eu/activities/risk- management/files/deliverables/cloud-computing-risk-assessment

Cloud Security Alliance. “Security Guidance for Critical Areas of Cloud Comput- ing Version 3.0.” November 14, 2011. https://cloudsecurityalliance.org/research/ security-guidance

ISACA. Control Objectives for Information and Related Technology (COBIT) v5: http://www.isaca.org/cobit

ISO/IEC 17799:200527002:2005: “Information Technology—Security Techniques— Code of Practice for Information Security Management.” www.iso.org/iso/home/ store/catalogue ics/catalogue detail ics.htm?csnumber=50297; http://www.iso .org/iso/iso catalogue/catalogue ics/catalogue detail ics.htm?csnumber=39612 (URL inactive).

Karygiannis, T., B. Eydt, G. Barber, L. Bunn, and T. Phillips. Guidelines for Securing Radio Frequency Identification (RFID) Systems. NIST Special Publication 800- 98. U.S. Department of Commerce, April 2007, http://csrc.nist.gov/publications/ nistpubs/800-98/SP800-98 RFID-2007.pdf

McKinney, D. U.S. Naval Research Laboratory, “NRL Designs Robot for Shipboard Firefighting.,” March 7, 2012. U.S. Naval Research Laboratory. www.nrl.navy .mil/media/news-releases/2012/nrl-designs-robot-for-shipboard-firefighting

NIST Cloud Computing: Information Technology Laboratory. www.nist.gov/itl/cloud/ index.cfm

Payment Card Industry Data Security Standard (PCI DSS): https://www .pcisecuritystandards.org

Sarbanes-Oxley Act of 2002. 15 U.S.C. 7201. Public Law 107-204. 107th Congress; www.sec.gov/about/laws/soa2002.pdf

Stouffer, K., J. Falco, and K. Scarfone. Guide to Industrial Control Systems (ICS) Security, Rev. 1. NIST Special Publication SP 800-82. U.S. Department of

Bosworth, S., Kabay, M. E., & Whyne, E. (Eds.). (2014). Computer security handbook, set. Retrieved from http://ebookcentral.proquest.com Created from apus on 2018-03-19 16:25:53.

C o p yr

ig h t ©

2 0 1 4 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

NOTES 53 · 31

Commerce, June, 2011. http://csrc.nist.gov/publications/nistpubs/800-82/ SP800-82-final.pdf

Ylonen, T., and C. Lonvick. “The Secure Shell (SSH) Protocol Architecture”. The Internet Engineering Task Force (IETF) Network Working Group RFC 4251. http://datatracker.ietf.org/doc/rfc4251 and http://tools.ietf.org/html/rfc4251

53.11 NOTES 1. For more information on intrusion detection systems and unified threat manage-

ment appliances, see Chapter 27 in this Handbook. 2. For more information about DoS attacks, see Chapter 18 in this Handbook. 3. For more information on incident response, see Chapter 56 in this Handbook. 4. Legislation on Notice of Security Breaches, National Conference of State Legis-

latures, www.ncsl.org/programs/lis/cip/priv/breach.htm 5. For more information on physical and facilities security, see Chapters 22 and 23

in this Handbook. 6. See Chapter 28 in thisHandbook for discussion of identification and authentication. 7. U.S. Department of Navy, “The Navy Unmanned Undersea Vehicle (UUV) Master

Plan,” November 9, 2004, www.navy.mil/navydata/technology/uuvmp.pdf 8. Department of Defense Directive No. 8100.1, “Global Information Grid (GIG)

Overarching Policy,” September 19, 2002, www.acq.osd.mil/ie/bei/pm/ref-library/ dodd/d81001p.pdf

9. Federal Energy Regulatory Commission, “Existing LNG Terminals,” www.ferc .gov/industries/gas/indus-act/lng/exist-term/everett.asp

10. Consortium for Electric Reliability Technology Solutions, “Demand-Response, Spinning-Reserve Demonstration—A New Tool to Reduce the Likelihood of Out- ages,” news release, July 26, 2006, http://certs.lbl.gov/press/press-7-26-06.html

11. See Chapter 3, page 3 in this Handbook. 12. K. Scarfone, M. Souppaya, A. Cody, and A. Orebaugh. NIST Special Publica-

tion 800-115, Technical Guide to Information Security Testing and Assessment, U.S. Department of Commerce, September 2008, http://csrc.nist.gov/publications/ nistpubs/800-115/SP800-115.pdf Keccak was announced as the winner of the five-year SHA-3 competition on October 3, 2012: http://csrc.nist.gov/groups/ ST/hash/sha-3

13. ZigBee Alliance: www.zigbee.org 14. U.S. Environmental Protection Agency, “Suggested Pre-Hurricane Activi-

ties for Water and Wastewater Facilities,” http://water.epa.gov/infrastructure/ watersecurity/emergencyinfo/pre-hurricane.cfm

15. Helix by e-Fense: www.e-fense.com/h3-enterprise.php 16. CERT R© Advisory CA-2003-04 MS-SQL Server Worm, January 27, 2003,

www.cert.org/advisories/CA-2003-04.html 17. An HP7925 120MB disk drive cost $25,000 in 1980, about $100,000 in 2013 cur-

rency. The cost per GB in 1980 was ∼$853,000 in 2008 dollars. In 2013, a Western Digital Caviar Green 3 TB SATA III 64 MB Cache Bare/OEM Desktop Hard Drive—WD30EZRX for sale at consumer stores cost ∼$123, or about $0.04/GB. The ratio of the change in cost is ∼4 × 10–7. Taking the 33rd root (2013–1980) of the change gives an annual cost change of ∼64 percent per year (37 percent decline per year compounded annually).

Bosworth, S., Kabay, M. E., & Whyne, E. (Eds.). (2014). Computer security handbook, set. Retrieved from http://ebookcentral.proquest.com Created from apus on 2018-03-19 16:25:53.

C o p yr

ig h t ©

2 0 1 4 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

53 · 32 MONITORING AND CONTROL SYSTEMS

18. U.S. Geological Survey, Fact Sheet 017-03, “The USGS Earthquake Hazards Pro- gram in NEHRP—Investing in a Safer Future,” by J. R. Filson, J. McCarthy, W. L. Ellsworth, and M. L. Zoback. Last modified May 17, 2005. http://pubs.usgs.gov/ fs/2003/fs017-03

19. Talisker Security Wizardry, The Computer Network Defence Internet Operational Picture, http://securitywizardry.com/radar.htm

20. For more information on software development and quality assurance, see Chap- ter 39 in this Handbook; for information on managing software patches, see Chapter 40.

21. For more information on jails, see Chapter 15 of the FreeBSD Documentation Project’s FreeBSD Handbook, contributed by Matteo Riondato: www.freebsd.org/ doc/en US.ISO8859-1/books/handbook/jails.html

Bosworth, S., Kabay, M. E., & Whyne, E. (Eds.). (2014). Computer security handbook, set. Retrieved from http://ebookcentral.proquest.com Created from apus on 2018-03-19 16:25:53.

C o p yr

ig h t ©

2 0 1 4 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

54CHAPTER

SECURITY AUDITS

Donald Glass, Richard O. Moore III, Chris Davis, John Mason, David Gursky, James Thomas, Wendy Carr, M. E. Kabay, and Diane Levine

54.1 INTRODUCTION 54 · 1

54.2 ADDRESSING MULTIPLE REGULATIONS FOR INFORMATION SECURITY 54 · 3 54.2.1 Gramm-Leach-Bliley

Act 54·5 54.2.2 Federal Information

Systems Management Act 54·5

54.2.3 Health Insurance Portability and Accountability Act of 1996 54·7

54.2.4 Payment Card Industry Data Security Standards 54·7

54.2.5 Publicly Available Security Publications 54·8

54.2.6 Risk Framework 54·10

54.3 AUDITING STANDARDS 54 · 10 54.3.1 Introduction to ISO 54·10 54.3.2 ISO/IEC 27000

Series 54·11 54.3.3 AICPA Security

Audit Standards 54·14 54.3.4 ISAE 3402

Standards 54·19

54.4 SARBANES-OXLEY ACT 54 · 20 54.4.1 Introduction 54·20 54.4.2 Section 404 54·20 54.4.3 Achieving

Compliance 54·21 54.4.4 Audit and

Certification 54·25 54.4.5 Sarbanes-Oxley

Conclusion 54·25

54.5 TECHNICAL FRAMEWORKS FOR IT AUDITS 54 · 26 54.5.1 Framework 1: People,

Processes, Tools, and Measures 54·26

54.5.2 Framework 2: STRIDE 54·26

54.5.3 Framework 3: PDIO 54·27 54.5.4 General Best

Practices 54·27 54.5.5 Technical

Frameworks Conclusion 54·28

54.6 FURTHER READING 54 · 28

54.7 NOTES 54 · 29

54.1 INTRODUCTION. Traditional auditing focused on reviewing organiza- tional financial records and controls to validate the accuracy and integrity of finan- cial data. External auditors typically focused on material or macro-level issues, and internal auditors focused primarily on transaction-level controls, protecting assets, and

54 · 1 Bosworth, S., Kabay, M. E., & Whyne, E. (Eds.). (2014). Computer security handbook, set. Retrieved from http://ebookcentral.proquest.com Created from apus on 2018-03-19 16:25:53.

C o p yr

ig h t ©

2 0 1 4 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

54 · 2 SECURITY AUDITS

validating information adequacy and validity. However, changes in the regulatory en- vironment over the past several years have caused a significant increase in the scope and depth of these responsibilities.

With the changed environment, the extent, focus, reliance, and quality of the audit work has increased significantly in quantity, depth, and reliance. Thus, the current busi- ness environment, whether global or domestic, increasingly requires routine, periodic security audits, and inspections that include compliance with:

� Legal requirements; e.g., U.S. Federal laws such as Sarbanes-Oxley (SOX), the Health Insurance Portability and Accountability Act (HIPAA), and the Gramm- Leach-Bliley Act (GLBA)

� Industry standards such as the Payment Card Industry Data Security Standard (PCI DSS) for organizations accepting credit card payments

� Auditing Standards, such as ISO 17799, ISO 27001, and ISO 27002, Statement of Auditing Standards (SAS) 70 audits, both Type I and Type II; and Statement on Standards for Attestation Engagements (SSAE) No. 16

These audits typically address networks, host systems, Internet-related connectivity, protection and detection devices, physical premises, and policy-related items on a recurring basis, since a static posture may unwittingly leave the organization vulnerable.

These reviews and audits may be regarded by an organization’s management with attitudes varying between two extremes:

1. They are a cost of doing business, one required by a regulator or governmental law.

2. It’s nice to have, but don’t spend too much money.

Both extremes, particularly the latter, ignore the value to the organization from such reviews, since the expense may be the primary (or only) criterion evaluated by senior management.

Sarah Abelow summarized the value of information technology (IT) audits as fol- lows:

1. Reduce risk. IT audits that are planned and executed based on best practices will identify and assess the risks in an organization’s IT environment. … Once risks are assessed, there can be clear vision on what course to take—to reduce or mitigate the risks through controls, to transfer the risk through insurance or to simply accept the risk as part of the operating environment …

2. Strengthen controls (and improve security). Based on the assessed risks as discussed above, the next step is to identify and assess corresponding controls. If controls are assessed to be poorly designed or ineffective, corrective action can be taken.

3. Comply with regulations. Wide ranging regulations at the federal and state levels include specific requirements for information security. The IT auditor serves a critical function in en- suring that specific requirements are met, risks are assessed and controls implemented. … It is critical to an organization to have assurance that all requirements are met.

4. Facilitate communication between business and technology management. An audit opens channels of communication between an organization’s business and technology management. Auditors spend time interviewing, observing, and testing what is happening in reality and in practice. An audit can provide valuable information in written reports and oral presentations. Senior management needs to know firsthand how their organization is functioning.

Bosworth, S., Kabay, M. E., & Whyne, E. (Eds.). (2014). Computer security handbook, set. Retrieved from http://ebookcentral.proquest.com Created from apus on 2018-03-19 16:25:53.

C o p yr

ig h t ©

2 0 1 4 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

ADDRESSING MULTIPLE REGULATIONS FOR INFORMATION SECURITY 54 · 3

The reverse communication from senior management to the technology professionals is also critical. Senior management’s objectives and expectations are communicated to the technology staff. Auditors can facilitate this communication through participation in technical meetings and through review of the current implementations of policies, standards, and guidelines. …

5. Improve IT Governance. The IT Governance Institute (ITGI) provides this definition: “IT Governance is the responsibility of executives and board of directors, and consists

of the leadership, organizational structures, and processes that ensure that the enterprise’s IT sustains and extends the organization’s strategies and objectives.”

The leadership, organizational structures, and processes mentioned in the definition point to IT auditors as key players. IT auditing and overall IT management are focused on the value, risks, and controls around an organization’s technology environment. IT auditors re- view the value, risks, and controls in all of the key components of technology—applications, information, infrastructure, and people.1

In addition, IT and security audits can help ensure that the organization is not unwittingly posing an IT-related risk for or threat to other organizations, whether related, foreign, competitor, peer, or unrelated, by becoming involved, even unwittingly, in national security breaches, industrial espionage or sabotage, computer trespass, privacy violations, spam, or harassment because of inadequate controls.

Recent developments in government regulation and oversight have reduced auditors’ gray areas; that is, the number of ambiguities and exceptions to requirements for reporting and compliance have been reduced. Perhaps as a result of increasing public awareness of leaks of personally identifiable information (PII), several undergraduate and graduate programs have been developed in universities and colleges around the world to train students in the discipline of IT, security, and compliance auditing.

Finally, it is useful to remind readers of the difference between an audit and an assessment:

� An audit is a formal process, usually carried out by a certified audit professional, focusing on verifying compliance with stated internal policies, external formal standards, and legal requirements. An audit report usually provides detailed lists of exactly which formal requirements have been met or not met.

� An assessment is an informal process, usually carried out by an industry expert who may or may not be certified by a professional body, focusing on improving efficiency and effectiveness, often using informal industry best practices and the expertise of the evaluator. An assessment report usually provides detailed analysis of failings and concrete recommendations for specific ways to improve what has been assessed.2

This chapter focuses on security audits.

54.2 ADDRESSING MULTIPLE REGULATIONS FOR INFORMATION SECURITY. Federal regulations and industry standards increasingly recognize the need to address controls related to information security. However, because of continual advances in technology and the diversity of equipment and structures available for use, regulations and standards have continued to be vague in stating specifically how security configurations should be implemented, tested, and monitored. Although there are many different clients from diverse industries, with various regulations, legislation, or industry specific standards, all of them have a fundamental source of their best practices.

Bosworth, S., Kabay, M. E., & Whyne, E. (Eds.). (2014). Computer security handbook, set. Retrieved from http://ebookcentral.proquest.com Created from apus on 2018-03-19 16:25:53.

C o p yr

ig h t ©

2 0 1 4 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

54 · 4 SECURITY AUDITS

During the 1980s, the Defense Computer Security Center began to create a series of standards related to securing computer systems for governmental and subcontracted entities. The series of documents relating to the configuration, auditing, and securing of systems is commonly referred to as the “Rainbow Series” because each cover in the series is a different color.3 Systems that followed the procedures of the series were considered trusted systems, due to the rigid requirements for following the configura- tion criteria contained within this series. The Rainbow Series documents have evolved into today’s Common Criteria Evaluation and Validation Scheme (CCEVS)4 to meet the demands of processing and computer systems of today; however, the fundamentals of how to secure and audit systems and information have remained semiconstant and have begun to be defined as best practices.

The term best practices is vague, but the concept comprises a set of standards, experiences, and after-action reports (lessons learned) that are intended to help meet the information security controls most commonly expected of trusted organizations. These best practices were derived from standards that were developed for secure or trusted systems. Today, information assurance best practices have evolved from the rigid requirements of the Rainbow Series standards. Best practices can now be found contained in various documents, including:

� Auditing checklists that can be obtained from the Information Systems Audit and Control Association (ISACA) as discussed in Section 54.4.3.3 in this chapter

� Defense Information Systems Agency’s Security Technical Implementation Guides (DISA-STIG)5

� National Institute of Standards and Technology (NIST) Computer Security Divi- sion’s Special Publications (SP) series—800 documents6

Another way to address the multiple regulations is to incorporate one of the more comprehensive frameworks, such as Control Objectives for Information and related Technology (COBIT, Section 54.4.3.3 in this chapter), Information Technology Infras- tructure Library (ITIL),7 and the International Organization for Standardization (ISO)8

27000 series (Section 54.3.2), with many relying on the others for ensuring that the information security areas have appropriate controls. Sections relevant to information security vary on the types of framework that should be incorporated but have value in that they identify areas that should have manual or technology controls pertinent to those areas.

For example, the Federal Information Security Management Act (FISMA) of 2002, the Sarbanes-Oxley Act of 2002, and the Health Insurance Portability and Account- ability Act of 1996 all address security policy, logical access controls, and methods for the handling and storage of sensitive information.

In the past, if help was needed to classify information, the Yellow Book, or the CSC-STD-003-85, was the reference or standard. Once information was appropriately classified, an information security classification policy was developed by the organi- zation and was applied to securing that data in information systems.

Today, legislative and industry specific requirements sometimes define what is crit- ical or sensitive information; for many organizations looking for answers, the starting reference is the NIST SP 800-60, Guide for Mapping Types of Information and Infor- mation Systems to Security Categories. The NIST SP 800 series provide a wealth of information to support effective IT and security audits.

Bosworth, S., Kabay, M. E., & Whyne, E. (Eds.). (2014). Computer security handbook, set. Retrieved from http://ebookcentral.proquest.com Created from apus on 2018-03-19 16:25:53.

C o p yr

ig h t ©

2 0 1 4 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

ADDRESSING MULTIPLE REGULATIONS FOR INFORMATION SECURITY 54 · 5

54.2.1 Gramm-Leach-Bliley Act. The Financial Services Modernization Act of 1999, more commonly known as the Gramm-Leach-Bliley Act (GLBA), regulates the security of consumers’ personal financial information and nonpublic personal in- formation (NPI). Major provisions of the GLBA address privacy requirements for information, disclosures of personal and financial information to third parties, rules re- garding the safeguarding of information, and protections against the use of pretexting to illegally acquire personal information.9 Financial information may include names of financial institution customers, account numbers, and information related to balances and transactions. NPI may include date of birth, Social Security number, driver’s li- cense number, financial account numbers, balances, home address, telephone numbers, and so on.

GLBA also governs the disclosure of such information to third parties. Institutions that are affected by GLBA must disclose to customers, in the form of a privacy notice, when and how their information is released. Additionally, institutions must provide for customers the opportunity to opt out of having their information shared with some third parties. Customers may not use the opt-out privileges to stop the release of their information to law enforcement agencies that are performing an authorized investigation.

GLBA regulations also protect consumers against the increasingly used form of social engineering called “pretexting.” Pretexting is the act of using false statements or impersonation to obtain access to the information of another individual. An example would be a perpetrator calling a financial institution and pretending to be an authorized account holder requesting to make a funds transfer by telephone. In the absence of face-to-face verification of a drivers’ license or some other token, banks are allowing such transactions to occur after the caller has verified some “known” information, be it date of birth, address, Social Security number, and so on. GLBA makes the act of pretexting illegal and encourages institutions to use more stringent methods for confirming a customer’s identity.

Internal auditing to determine compliance with GLBA protects organizations and ensures the proper handling of NPI. Because mishandling or unauthorized release of NPI can lead to incidents of fraud and identity theft, institutions that are required to use and maintain such information must be very diligent in their security processes. Periodic audits of business and network processes that control the storage, transmission, and use of NPI will aid in alerting organizations to weaknesses in their security and will document due diligence efforts in the protection of customer information.

For more details of compliance with GLBA, see Chapter 64 in this Handbook.

54.2.2 Federal Information Systems Management Act. FISMA affects almost all U.S. Governmental entities and was created as part of the E-Government Act (Public Law 107-347)10 passed by the 108th Congress in 2002 and signed into law by then President George W. Bush. The resolution recognized the importance of information security to the economic and national security interests of the United States. Title III of the E-Government Act entitled the FISMA11 to require each federal agency to develop, document, and implement an agency-wide information assurance program that would provide security controls for the information and systems that support the operations and assets of the agency. This measure should also include security controls for information-handling services or systems that are provided, or managed, by third-party agencies, contractors, or other sources.

Bosworth, S., Kabay, M. E., & Whyne, E. (Eds.). (2014). Computer security handbook, set. Retrieved from http://ebookcentral.proquest.com Created from apus on 2018-03-19 16:25:53.

C o p yr

ig h t ©

2 0 1 4 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

54 · 6 SECURITY AUDITS

FISMA defined what should be included in an information-security program to be effective:

� Periodic assessments of risk, including the magnitude of harm that could result from the unauthorized access, use, disclosure, disruption, modification, or de- struction of information and information systems that support the operations and assets of the organization (Many corporate entities may refer to this as a business impact analysis [BIA].)

� Policies and procedures that are based on the information provided by risk as- sessments, that would cost effectively reduce information security risks to an acceptable level, and that would ensure that information security is addressed throughout the life cycle of each organizational information system

� Subordinate plans for providing adequate information security for networks, fa- cilities, information systems, or groups of information systems, as appropriate

� Security awareness training to inform personnel (including contractors and other users of information systems that support the operations and assets of the or- ganization) of the information-security risks associated with their activities and their responsibilities in complying with organizational policies and procedures designed to reduce these risks

� Periodic testing and evaluation of the effectiveness of information-security poli- cies, procedures, practices, and security controls will be performed, with frequency determined by the level of risk, but no less than annually

� A process for planning, implementing, evaluating, and documenting remedial ac- tions to address any deficiencies in the information-security policies, procedures, and practices of the organization

� Procedures for detecting, reporting, and responding to security incidents � Plans and procedures to ensure continuity of operations for information systems that support the operations and assets of the organization

FISMA, along with the Paperwork Reduction Act of 1995 and the Information Technology Management Reform Act of 1996 (Clinger-Cohen Act), explicitly empha- sizes a risk-based policy for cost-effective security. In supporting and reinforcing this legislation, the Office of Management and Budget (OMB) through Circular A-130, Ap- pendix III, Security of Federal Automated Information Resources,12 requires executive agencies within the federal government to:

� Plan for security � Ensure that appropriate officials are assigned security responsibility � Periodically review the security controls in their information systems � Authorize system processing prior to operations and periodically thereafter

These management requirements presume that responsible agency officials under- stand the risks and other factors that could adversely affect their objectives. Moreover, these officials must understand the status of their security programs, and the security controls planned or in place to protect their information and information systems, in order to make informed judgments and investments that appropriately mitigate risk to an acceptable level.

Bosworth, S., Kabay, M. E., & Whyne, E. (Eds.). (2014). Computer security handbook, set. Retrieved from http://ebookcentral.proquest.com Created from apus on 2018-03-19 16:25:53.

C o p yr

ig h t ©

2 0 1 4 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

ADDRESSING MULTIPLE REGULATIONS FOR INFORMATION SECURITY 54 · 7

The ultimate objective is to conduct the day-to-day operations of the agency and to accomplish the agency’s stated missions with security commensurate with level of risk, while acknowledging the magnitude of harm that could result from the unauthorized access, use, disclosure, disruption, modification, or destruction of information. As a key element of the FISMA Implementation Project, NIST also developed an integrated risk framework13 that effectively brings together all of the FISMA-related security standards and guidance, in order to promote the development of comprehensive and balanced information-security programs by agencies.14

54.2.3 Health Insurance Portability and Accountability Act of 1996. The Health Insurance Portability and Accountability Act (HIPAA),15 42 USC 201 et seq., includes specific provisions affecting information security:

The Office for Civil Rights enforces the HIPAA Privacy Rule, which protects the privacy of individually identifiable health information; the HIPAA Security Rule, which sets national standards for the security of electronic protected health information; the HIPAA Breach No- tification Rule, which requires covered entities and business associates to provide notification following a breach of unsecured protected health information; and the confidentiality provi- sions of the Patient Safety Rule, which protect identifiable information being used to analyze patient safety events and improve patient safety.16

For extensive discussion of HIPAA, see Chapter 71 in this Handbook.

54.2.4 Payment Card Industry Data Security Standards. The Payment Card Industry Security Standards Council was formed in 2006 by collaboration of American Express, Discover Financial Services, JCB International, MasterCard World- wide, and Visa Inc. The Council has promulgated the

� Payment Card Industry Data Security Standard (PCI DSS) for “merchants and entities that store, process, or transmit cardholder data”

� Payment Application Data Security Standard (PA-DSS) for software developers � PIN Transaction Security (PTS) requirements for manufacturers of card-reading equipment.17,18

The core goals of the PCI DSS are summarized in the organization’s table of goals and requirements as shown in Exhibit 54.1.18

The official site19 has an extensive range of documents available at no cost (simple registration required), including (as of July 2013):

� FAQs for use with ROC [Report on Compliance] Reporting Instructions for PCI DSS v2.0

� Glossary v2.0 � Navigating the PCI DSS v2.0 � PCI DSS AOC—Merchants v2.0 � PCI DSS AOC—Service Providers v2.0 � PCI DSS Quick Reference Guide v2.0 � PCI DSS Summary of Changes Version 1.2.1 to 2.0 � PCI Quick Reference Order Form

Bosworth, S., Kabay, M. E., & Whyne, E. (Eds.). (2014). Computer security handbook, set. Retrieved from http://ebookcentral.proquest.com Created from apus on 2018-03-19 16:25:53.

C o p yr

ig h t ©

2 0 1 4 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

54 · 8 SECURITY AUDITS

EXHIBIT 54.1 Organization’s Goals and Responsibilities

Goals PCI DSS Requirements

Building and Maintain a Secure Network

1. Install and maintain a firewall configuration to protect cardholder data

2. Do not use vendor-supplied defaults for system passwords and other security parameters

Protect Cardholder Data 3. Protect stored cardholder data 4. Encrypt transmission of cardholder data across

open public networks

Maintain a Vulnerability Management Program

5. Use and regularly update anti-virus software or program

6. Develop and maintain secure systems and applications

Implement Strong Access Control Measures

7. Restrict access to cardholder data by business need to know

8. Assign a unique ID to each person with computer access

9. Restrict physical access to cardholder data

Regularly Monitor and Test Network

10. Track and monitor all access to network resources and cardholder data

11. Regularly test security systems and processes

Maintain an Information Security Policy

12. Maintain a policy that addresses information security for all personnel

� Prioritized Approach for PCI DSS Version 2.0 � Prioritized Approach Tool Version 2.0 � ROC Reporting Instructions for PCI DSS v2.0 � Summary of Changes from Prioritized Approach for PCI DSS Version 1.2 to 2.0 � Summary of PCI DSS and PA-DSS Feedback 2012

The specific guidelines can be integrated into audit patterns adapted for the require- ments of each organization handling credit card data.

54.2.5 Publicly Available Security Publications. The NIST SP (SP) 800- 53 Revision 1 is the “Recommended Security Controls for Federal Information Systems.”20 The purpose of SP 800-53 is to provide guidelines for selecting and specifying what should be security controls for information systems supporting the executive agencies of the federal government. The guidelines have been developed to help achieve secure system requirements by:

� Facilitating a more consistent, comparable, and repeatable approach for selecting and specifying security controls for information systems

Bosworth, S., Kabay, M. E., & Whyne, E. (Eds.). (2014). Computer security handbook, set. Retrieved from http://ebookcentral.proquest.com Created from apus on 2018-03-19 16:25:53.

C o p yr

ig h t ©

2 0 1 4 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

ADDRESSING MULTIPLE REGULATIONS FOR INFORMATION SECURITY 54 · 9

� Providing a recommendation for minimum security controls for information sys- tems categorized in accordance with Federal Information Processing Standard (FIPS) 199,21 Standards for Security Categorization of Federal Information and Information Systems

� Providing a stable yet flexible catalog of security controls for information sys- tems to meet current organizational protection needs and the demands of future protection needs based on changing requirements and technologies

� Creating a foundation for the development of assessment methods and procedures for determining security control effectiveness

The guidelines provided in SP 800-53 are applicable to all federal information systems22 with the exception of systems designated as national security systems as defined by 44 USC Section 3542.23 The guidelines have been broadly developed from a technical perspective to complement similar guidelines for national security systems. This publication is intended to provide guidance to federal agencies implementing FIPS 200,24 Minimum Security Requirements for Federal Information and Information Systems. In addition to the agencies of the federal government, the state, local, tribal governments, and private-sector organizations that comprise the critical infrastructure of the United States are also encouraged to use these guidelines as appropriate.

The security controls in SP 800-53 have been developed using inputs from a variety of sources including NIST SP 800-26, Department of Defense (DoD) Policy 8500, Di- rector of Central Intelligence Directive (DCID) 6/3, ISO/IEC Standard 17799, General Accounting Office (GAO) Federal Information System Controls Audit Manual (FIS- CAM), and Health and Human Services (HHS) Centers for Medicare and Medicaid Services (CMS) Core Security Requirements. The security controls cover these topic areas25:

� Access control � Accountability and audit � Awareness and training � Certification, accreditation, and security assessments � Configuration management � Contingency planning � Identification and authentication � Incident response � Maintenance � Media protection � Personnel security � Physical and environmental protection � Risk assessment � Security planning � System and communications protection � System and information integrity � System services and acquisition

Bosworth, S., Kabay, M. E., & Whyne, E. (Eds.). (2014). Computer security handbook, set. Retrieved from http://ebookcentral.proquest.com Created from apus on 2018-03-19 16:25:53.

C o p yr

ig h t ©

2 0 1 4 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

54 · 10 SECURITY AUDITS

54.2.6 Risk Framework. The following list illustrates an example of how to create a security-audit framework that draws on a wide array of audit standards:

1. Categorize the information system and the information resident within that system based on impact. (FIPS 199iii and NIST SP 800-6026)

2. Select an initial set of security controls for the information system based on the FIPS 199 security categorization and apply tailoring guidance, as appropriate, to obtain a starting point for required controls. (FIPS 200 and NIST SP 800-53)

3. Supplement the initial set of tailored security controls based on an assessment of risk and local conditions, including organization-specific security require- ments, specific threat information, cost-benefit analyses, and special circum- stances. (NIST SP 800-53 and SP 800-3027)

4. Document the agreed-on set of security controls in the system security plan, including the organization’s justification for any refinements or adjustments to the initial set of controls. (NIST SP 800-1828)

5. Implement the security controls in the information system 6. Assess the security controls using appropriate methods and procedures to deter-

mine the extent to which the controls are implemented correctly, operating as intended, and producing the desired outcome with respect to meeting the security requirements for the system. (NIST SP 800-53A29)

7. Authorize information system operation based on a determination of the risk to organizational operations, organizational assets, or to individuals resulting from the operation of the information system and the decision that this risk is acceptable. (NIST SP 800-3730)

8. Monitor and assess selected security controls in the information system on a con- tinuous basis including documenting changes to the system, conducting security impact analyses of the associated changes, and reporting the security status of the system to appropriate organizational officials on a regular basis.31

54.3 AUDITING STANDARDS. Auditing standards and practices assist organi- zations in meeting regulatory requirements and provide industry guidance for ensuring due diligence, certification, and ensuring stakeholder security. As discussed in the preceding section, standard-setting entities include international organizations, federal and state levels of government, and industry-specific groups or associations whose fo- cus includes regulatory compliance. Guiding principles and information published by these entities may be required or, at the very least, provide managers with the newest information regarding industry advances. Managers must not only be aware of new developments in auditing methodology; they must also be adept in identifying and applying the best solution available to their unique physical and logical architecture.

54.3.1 Introduction to ISO. ISO32 is a nongovernmental cooperative of inter- national members who work together to create, identify, and publish industry standards as they relate to business and technology. Membership comprises member bodies, correspondent members, and subscriber members.

� A member body is a group that represents the accepted standards of a specific country.

Bosworth, S., Kabay, M. E., & Whyne, E. (Eds.). (2014). Computer security handbook, set. Retrieved from http://ebookcentral.proquest.com Created from apus on 2018-03-19 16:25:53.

C o p yr

ig h t ©

2 0 1 4 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

AUDITING STANDARDS 54 · 11

� Correspondentmembers represent a country that does not yet have fully developed standards.

� Subscriber members represent countries with developing economies.33

Level of membership determines technical and policy participation and voting priv- ileges, but members all are equally represented in international standardization and are encouraged to contribute.

Standards are developed based on industry interest; needs of vendors, governments, and consumers; and initiatives of the ISO where it sees market interest. Once the idea of a standard has been recognized by the ISO, member committees begin the process of defining the technical requirements necessary for the standard. Committee members include technical experts representing countries interested in the potential new standard. Once the technical requirements have been defined, interested members and countries work toward agreement on detailed specifications for the standard. When final details have met committee approval, a draft of the international standard is released for review. Final release of an official ISO standard34 requires approval of two-thirds of the members who participated in the development process and 75 percent of all members who vote.35

Standards established by ISO are not regulator; they represent best-practice guidance that is globally consistent for a given trade or line of business. Widespread acceptance and implementation of ISO standards and guidance further elevates them as identifiers of distinction within a given industry. Similar to worldwide recognition of ISO 9000 and ISO 14000 as standards for Quality and for Environmental Management (respectively), the ISO 27000 series is quickly becoming accepted as the measurement of excellence in information-security management.

54.3.2 ISO/IEC 27000 Series. Information and network security has been a concern since the early days of worms and viruses; however, it has only been in the past 15 to 20 years that structures have been defined to integrate security with network use and risk management. Introduction of BS7799 and its acceptance by ISO have given administrators the long-needed tools to identify and manage these domains. Additionally, regulations such as the Sarbanes-Oxley Act of 2002 (SOX), the Gramm-Leach-Bliley Act (GLBA), Health Insurance Portability and Accountability Act (HIPAA), and the Federal Information Security Management Act (FISMA) have set down compliance requirements that are more easily achievable with a comprehensive information-security management system in place.

British Standard 7799, representing best practices for information security, was first published in February 1995. This three-part standard encompasses security ob- jectives and controls as well as the development methodology necessary to create an information-security management system (ISMS).36

� BS7799: Part 1, Best Practices for Information Security Management � BS7799: Part 2, Defines specifications for information-security management sys- tems

� BS7799: Part 3, Guidelines for information-security risk management

In the past decade, British Standard 7799 was the basis for the ISO 17799 and then into the ISO 27000 series, which continues to evolve as a widely accepted standard for information-security management and for operational procedure guidance. Both

Bosworth, S., Kabay, M. E., & Whyne, E. (Eds.). (2014). Computer security handbook, set. Retrieved from http://ebookcentral.proquest.com Created from apus on 2018-03-19 16:25:53.

C o p yr

ig h t ©

2 0 1 4 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

54 · 12 SECURITY AUDITS

agencies (and their collective members) understood the need for a comprehensive program that addressed the risk management and auditing needs of organizations while defining a framework for programs and policies to support this concept. Partial or full implementation of these standards not only prepares organizations for audits and risk assessments but can also help them meet regulatory requirements.

The ISMS defined by BS7799 and further improved on by ISO 17799 and ISO/IEC 27000 is a means to ensure the best environment not only for security practices but also for objective auditing and assessments. An organization’s interpretation of, and adherence to, the ISMS model can be a major indicator of the security climate of the organization as well as of management’s support of policies and procedures. Programs that support ISMS functions must be promoted and used by management to demonstrate their significance to employees and to encourage participation. Audits typically consist of a planning phase, the actual audit process, and the final report to the audit committee presenting the details of audits or assessments.

In December 2000, BS7799 Part 1 (Best Practices for Information Security Man- agement) was revised and released as ISO 17799.37 The ISO 17799 standard comprises 10 domains:

1. Business continuity planning 2. System access control 3. System development and maintenance 4. Physical and environmental security 5. Compliance 6. Personnel security 7. Security organization 8. Computer and operations management 9. Asset classification and control 10. Security policy

In 2005, ISO completed a cooperative effort with the International Electrotech- nical Commission to release ISO/IEC 17799:2005. This release, entitled Information Technology—SecurityTechniques—CodeofPracticeforInformationSecurityManage- ment, added objectives and controls for information-security management and updated the previous release to include advances in technology (mobile and wireless) and in applications and uses of the Internet.38

BS7799 and ISO 17799 established widely implemented guidance for the information-security management systems standard, but the evolutionary path of their published standards has made them nearly obsolete. The ISO/IEC 2700039 set of stan- dards not only incorporates the guidance of BS7799 and ISO 1779940 but also provides a more thorough explanation and understanding of each domain by partitioning them into distinctly separate standards. The ISO/IEC ISMS family includes the following International Standards (as of July 2013):

� ISO/IEC 27000:2009, Information security management systems—Overview and vocabulary

� ISO/IEC 27001:2005, Information security management systems—Requirements � ISO/IEC 27002:2005, Code of practice for information-security management

Bosworth, S., Kabay, M. E., & Whyne, E. (Eds.). (2014). Computer security handbook, set. Retrieved from http://ebookcentral.proquest.com Created from apus on 2018-03-19 16:25:53.

C o p yr

ig h t ©

2 0 1 4 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

AUDITING STANDARDS 54 · 13

� ISO/IEC 27003:2010, Information-security management system implementation guidance

� ISO/IEC 27004:2009, Information-security management—Measurement � ISO/IEC 27005:2011, Information-security risk management � ISO/IEC 27006:2011, Requirements for bodies providing audit and certification of information-security management systems

� ISO/IEC 27007:2011, Guidelines for information-security management systems auditing

� ISO/IEC 27010:2012, Information-security management guidelines for inter- sector and interorganizational communications

� ISO 27799:2008, Health informatics—Information-security management in health using ISO/IEC 27002

� ISO/IEC FDIS 27013, Guidance on the integrated implementation of ISO/IEC 27001 and ISO/IEC 20000-1

� ISO/IEC TR 27008:2011, Guidelines for auditors on information-security man- agement systems controls

� ISO/IEC TR 27015, Information-security management guidelines for financial services

� ISO/IEC WD 27016, Information-security management—Organizational eco- nomics

� ITU-T X.1051 | ISO/IEC 27011:2008, Information-security management guide- lines for telecommunications organizations based on ISO/IEC 27002

� ITU-T X.1054 | ISO/IEC FDIS 27014, Governance of information security

Some ISO standards are freely available in electronic form from http://standards.iso .org/ittf/PubliclyAvailableStandards/index.html and they may also be purchased as electronic or printed documents from http://www.iso.org/iso/home/store.htm

ISO/IEC 27001 (ISMS Requirements) closely models the Organization for Eco- nomic Cooperation and Developments (OECD)41 guidance on the security of informa- tion systems and networks, and is driven by the Plan-Do-Check-Act (PDCA) cycle.42

The PDCA cycle, developed by W. Edwards Deming in the 1950s, asks managers to view business processes as being in a constant feedback loop.43 This method allows managers to be involved more thoroughly in the entire change control and improvement process.

Organizations may implement some or all of the standards of ISO/IEC 27001 or take their program a step further by applying for ISMS certification. Certification pro- vides both auditors and stakeholders with the assurance that a comprehensive program is in place for information-security and business systems. Whether an organization seeks recognized ISMS certification or not, there are several advantages to adopting the objectives and controls outlined in ISO/IEC 27001. As stated earlier, having a com- prehensive ISMS program in place can greatly contribute to compliance in other areas. An ISO/IEC 27001-certified ISMS will ensure compliance with the whole range of information-security–related legislation, including HIPAA, GLBA, and FISMA regu- lations, as well as the conditions for a successful Sarbanes-Oxley Section 404 report.44

Documented ISMS policies and programs, a security climate including both man- agement and employees, and adherence to policy are not only necessary for an

Bosworth, S., Kabay, M. E., & Whyne, E. (Eds.). (2014). Computer security handbook, set. Retrieved from http://ebookcentral.proquest.com Created from apus on 2018-03-19 16:25:53.

C o p yr

ig h t ©

2 0 1 4 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

54 · 14 SECURITY AUDITS

information-security management system to be effective, but will ensure a success- ful, constructive, and effective audit process.

54.3.3 AICPA Security Audit Standards. Companies and government agen- cies are under constant pressure to improve efficiencies and to reduce operational costs. In addition, public companies are being driven by investors and shareholders to im- prove profitability, contributing in a small way to IT outsourcing in the 2000s. The U.S. Bureau of Labor Statistics began including “Cost control/cost cutting/increase prof- itability” as a reason for mass layoffs starting with the 2007 studies; the proportions of respondents using this entry as a reason for the layoffs were stable at approximately 3 percent of total yearly layoffs between 2007 and 2011.45

Outsourcing has not been limited to public companies; government agencies have also embraced outsourcing to contain costs. In 2013, data from the U.S. Federal Office of Management and Budget suggested that about one-third of all U.S. Government discretionary spending was outsourced.46

With the drive for more companies to focus on their core competencies, these types of business functions are being outsourced:

� Claims processing � Customer service and helpdesk � Data processing � Financial and accounting � Human resources and benefit plans � Web hosting

Executive officers of organizations considering outsourcing must understand both the benefits and the risks; they also have to mitigate the risk to a level acceptable for their organizations.

The American Institute of Certified Public Accountants (AICPA) has defined three widely used security-audit standards, discussed in the following sections:

� SAS 70 � SSAE 16

ISAE 3402 is an international standard with which SSAE 16 complies.

54.3.3.1 Introduction to SSAE 16 Audits. The Statement of Auditing Stan- dards No. 70 (SAS 70): Service Organizations, was originally created by the American Institute of Certified Public Accountants (AICPA) for financial-service reporting and was a key method of ensuring that a company being considering for supplying out- sourced services met security requirements.47

The security-audit industry’s need to report on security controls has led to the replacement of SAS 70 by the Statement on Standards for Attestation Engagements No. 16 (SSAE 16), Reporting on Controls at a Service Organization, which replaced the guidance for service auditors in SAS 70 for all such engagements ending on or after June 15, 2011.

Bosworth, S., Kabay, M. E., & Whyne, E. (Eds.). (2014). Computer security handbook, set. Retrieved from http://ebookcentral.proquest.com Created from apus on 2018-03-19 16:25:53.

C o p yr

ig h t ©

2 0 1 4 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

AUDITING STANDARDS 54 · 15

EXHIBIT 54.2 Types of SSAE 16 Audits

SSAE 16 Report Content Type I Type II

Independent service audits report Included Included Service organization’s description of controls Included Included Information provided by the independent service auditor; includes a description of the service auditor’s tests of operating effectiveness and the results of those tests

Optional Included

Other service relevant information Optional Included

SSAE 16 was also “drafted with the intention and purpose of updating the US service organization reporting standard so that it mirrors and complies with the new international service organization reporting standard—ISAE 3402.”48

In addition to being used for evaluating outsourcing suppliers, the SSAE 16 can be used when partnering with companies that may have access to your IT resources and data—especially personally identifiable information (PII) about customers.

In this section, the two types of SSAE 16 audits and their components are described.

Terminology associated with SSAE 16 audits: Service organization—the company that will process information or transactions

on behalf of the user organization

Service auditor—retained by the service organization to conduct an SSAE 16 audit and provide a certification of audit results

User organization—the company that outsourced services and is the customer of the service organization

Users’ auditors—either an internal or external auditing group that provides auditing services to the user organization

SOC—service organization controls; there are three types of SOC reports

The SSAE 16 defines the professional standards that are used by the service auditor, who will be assessing the internal controls that a service organization has implemented.

An SSAE 16 audit provides authoritative guidance that allows a service organization to disclose its control processes and activities to potential customers and to external auditors; the information is presented in a standard reporting format. There are three different types (SOC-1, -2, and -3) and two different levels of SSAE 16 audits (Type I and Type II), as illustrated in Exhibit 54.2.

� SOC-1: Controls at a service organization that are relevant to the user entity’s internal controls over financial reporting; these can include both IT-related as well as financial controls. This report can be used by all types of service organizations; data centers may use this type of report in place of a SOC-2 if one or more financially related controls are reviewed.

� SOC-2: Strictly an IT-focused report with the controls preestablished and orga- nized into the categories of security, availability, processing integrity, confiden- tiality, and privacy. The service organization may choose to have the audit focus on selected categories; all controls within the selected category/categories must be reviewed. Typically, these apply to data centers, ISPs, and ASPs.

Bosworth, S., Kabay, M. E., & Whyne, E. (Eds.). (2014). Computer security handbook, set. Retrieved from http://ebookcentral.proquest.com Created from apus on 2018-03-19 16:25:53.

C o p yr

ig h t ©

2 0 1 4 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

54 · 16 SECURITY AUDITS

� SOC-3: Similar to a SOC-2, this report focuses on trust services and principles; e.g., a Web trust audit. If the service organization elects to include the privacy principle in the audit scope, the criteria for the content of a privacy notice is included. This typically includes information about collecting the information, the choices that the individuals have regarding their personal information, the security of the information, and how the individuals can contact the service organization for inquiries, complaints, or disputes.

Each report contains several key sections:

� Opinion letter from the CPA firm. � Management assertion regarding the description of the service organization’s system and the suitability of the design of the controls; if the report is a Type II, then the assertion also includes the operating effectiveness of the controls in achieving the control objectives.

� Description of the controls and control environment. � Results of the controls’ testing. � Key subservice organizations (e.g., outsourced IT monitoring) whose activities affect the controls.

A critical difference between an SSAE 16 Type I audit and Type II is that a Type I audit tests the control design effectiveness and tests one sample transaction for each control; this, to prove that the design of the control functions appropriately in at least one instance. For a Type II audit, the control design is tested as well as the controls’ effectiveness over the audit period. Because of this testing, Type II audits are more costly but provide a detailed report and provide more value and reliance to the service organizations’ users.

An SSAE 16 audit starts with the service auditor conducting an initial risk assessment and evaluation of the processing system and of the transaction systems processing controls, and a review of the policies and procedures that govern IT system and processes. Next, the auditor will develop a statement of work (SOW) that will be presented to the service organization with completion date, details of the audit, audit scope, and cost.

An SSAE 16 audit team usually will be managed by a CPA; a CPA must review the audit report and work and must sign the opinion. This individual will be the primary interface with the customer executive management and will certify the audit results. The audit team performing the work may be a single person or a team of perhaps two to four auditors. The technical lead is responsible for evaluation and testing of systems and network devices.

If a SOC-1 audit is being performed, there may be two to five IT-related control objectives, and within each control objective, there may be one to fifteen controls tested. Typically, there is more granularity in the testing of the controls, so that if a particular control fails (e.g., not disabling a terminated user’s access promptly), then it would not cause other controls bundled together to fail (e.g., if user provisioning—add, change, or remove users—is listed as a single control instead of three controls). For an SOC-1 audit, the service organization is responsible for identifying and approving the control objectives and the controls; the service auditor often provides information as to best practices and controls that typically are tested. For the SOC-2 and SOC-3 reports, the controls are preestablished, and the service organization may select which of the key categories are to be reviewed in the audit.

Bosworth, S., Kabay, M. E., & Whyne, E. (Eds.). (2014). Computer security handbook, set. Retrieved from http://ebookcentral.proquest.com Created from apus on 2018-03-19 16:25:53.

C o p yr

ig h t ©

2 0 1 4 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

AUDITING STANDARDS 54 · 17

In addition to reviewing hardware and software configurations, IT policies and procedures typically are included to be evaluated, reviewed, and verified. Management, including system and network administrators, will be interviewed in the walkthrough phase to determine how certain tasks are performed; a sample item will be tested at that time to verify that the control’s design is effective (i.e., that the control works for a sample transaction). For example, who approves a user account request form, and how does the form flow through the approval process? System or application administrators will be asked to explain what they do from the time they receive an account request form until the account is created. The auditor will use the information gathered from the interviews to determine if account policies and procedures are being followed and if they are adequate for the customer’s environment.

A brief overview of what an auditor would review for a user request policy and how the results would be reported follows:

� Policy statement. All users who require a new computer account or modification to an existing account, on any system at the company will be required to complete User Account Request Form UA-09.

� Policies and procedures. User Account Request Policy “IT-23 November 1, 2011.” All requests for a new account or for modification of an existing account must be submitted on a UA-09 Form.

� Test procedure. Conduct a sample review of user request forms and review the forms for proper authorized signatures and completeness. Interview authorized signers for compliance with user request policy; ensure that users are only given roles consistent with their job position’s least privileges.

� Test results. Collect statistical samples of user request forms and interview the supervisors of the individuals making the requests to determine that least privileges needed to perform their job have been requested and approved. Check forms for completeness and accuracy of information.

� Analysis of test results. The auditor will provide both the positive test results and negative results with commentary. A sample of a positive or negative test results: � Positive test result. All forms that were reviewed were completed in accor- dance with User Account Request Policy “IT-23 November 1, 2011,” and all interviews indicated that all policies and procedures were correctly followed. No discrepancies were found.

� Negative test result. After reviewing the User Account Request Form and interviewing supervisors and authorized signers, it was determined that User Account Request Policy “IT-23 November 1, 2011” was not followed. Users were given privileges beyond what was required to perform their job.

Exceptions and findings are reported in the final SSAE 16 report sent to management in these ways:

� If the auditor deems that it is relevant, an exception is reported, including a description of the exception.

� The auditor will consider any mitigating controls or any management responses to the exception.

� If, in the auditor’s opinion, the finding has an impact on the control objectives, then it would be reported with a qualified opinion and potential impact; if not, it would be reported as an exception.

Bosworth, S., Kabay, M. E., & Whyne, E. (Eds.). (2014). Computer security handbook, set. Retrieved from http://ebookcentral.proquest.com Created from apus on 2018-03-19 16:25:53.

C o p yr

ig h t ©

2 0 1 4 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

54 · 18 SECURITY AUDITS

The final document that a SSAE 16 will provide is the conclusion and summary report, which will clearly state whether the description of the controls is accurately and fairly presented. The report will also state whether the controls were adequately designed to meet their control objectives. The report for a Type II audit would also include the results of tests that were performed and would evaluate whether they provide reasonable assurance that controls were operating correctly during a period of time, normally no less than six months and no more than 12 months; however, for the first SSAE 16, a service organization must have a minimum review period of three months.

54.3.3.2 Cost and Benefits of SSAE 16 Audits. Before undertaking an SSAE 16 audit, any organization, whether a service provider or an outsourcing com- pany, must decide whether such a procedure is worth the costs. For example, a small service organization whose customer requests an SSAE 16 audit must determine whether to keep that customer: an initial audit Type II SSAE 16 audit’s cost can range from $15,000 to over $1 million, in addition to the annual cost to keep the au- dit current. Because of the reduced testing, a Type I may be engaged for $10,000 to $13,000, depending on the number of controls, the control objectives, and the extent that the service auditor (SSAE 16 auditor) can rely on the service organization’s internal audit work.

User organizations have quickly embraced the SSAE 16 audit because of the benefits in complying with the SOX and GLBA requirements. Depending on the scope and timing of the audit, regulators and/or financial auditors may be able to place reliance on the audit and reduce their own audit scopes; this can translate into time and expense savings.

The audit can help foster business development activities, since an SSAE 16 audit is frequently regarded as an affirmation of the service organization’s commitment to quality and security; the audit report can also provide benefits and reduce paperwork when responding to requests for proposal (RFPs) or similar offerings.

SSAE 16 has adopted the Committee of Sponsoring Organizations of the Treadway Commission (COSO) as its standard for reviewing internal controls.49 The COSO definition of internal control is “a process, effected by an entity’s board of directors, management and other personnel, designed to provide reasonable assurance regarding the achievement of objectives.” Also, COSO is the same standard that Sarbanes-Oxley Section 404 has adopted for how to review internal controls. See Section 54.5.3.2 for further details of COSO.

The SSAE 16 has pros and cons for both the service organization and user organi- zation; these issues must be understood so that management can perform a cost-benefit analysis (see Exhibit 54.3).

54.3.3.3 SSAE 16 Audits Conclusion. In conclusion, an SSAE 16 audit is not a 100 percent guarantee of assurance that all security-related controls and processes have been correctly designed and implemented; after all, the service organization selects the controls to be tested in an SOC-1 engagement. For SOC-2 or SOC-3 engagements, high-value control objectives and controls are included; however, they do not cover all possible controls. Nonetheless, an SSAE 16 audit provides a high-level of confidence that risks have been assessed and mitigated.

The SSAE 16 audit results can also provide information about areas for further investigation. A major benefit of an SSAE 16 audit is that it can be used to meet the reporting requirements for SOX Section 404 reporting, help in meeting GLBA and

Bosworth, S., Kabay, M. E., & Whyne, E. (Eds.). (2014). Computer security handbook, set. Retrieved from http://ebookcentral.proquest.com Created from apus on 2018-03-19 16:25:53.

C o p yr

ig h t ©

2 0 1 4 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

AUDITING STANDARDS 54 · 19

EXHIBIT 54.3 Pros and Cons for Service and User Organizations

Factor Service

Organization User

Organization

Independent assessment of controls Pro Pro Lower cost for evaluation of controls Con Pro No additional review of controls required Con Con SSAE 16 audits are forward looking Con Con SSAE 16 audits must be continuously reviewed and updated

Con Pro

SSAE 16 audits increase the value of services Pro Pro Disruption to service organization is reduced by eliminating user organization auditors from visiting service organization to conduct audit

Pro Pro

The SSAE 16 audit can be used to build a strong working relationship between organizations

Pro Pro

Audit results can provide opportunities for improvements

Pro Pro

HIPAA compliance, and may provide benefits as a marketing tool regarding service quality.

54.3.4 ISAE 3402 Standards. The International Standard on Assurance En- gagements (ISAE) No. 3402, Assurance Reports on Controls at a Service Organization, is the international standard under which SSAE 16 has been approved:

[ISAE 3402] was issued in December 2009 by the International Auditing and Assurance Standards Board (IAASB), which is part of the International Federation of Accountants (IFAC). ISAE 3402 was developed to provide an international assurance standard for allowing public accountants to issue a report for use by user organizations and their auditors (user auditors) on the controls at a service organization that are likely to impact or be a part of the user organization’s system of internal control over financial reporting.50

Ernst & Young describe ISAE 3402 as follows in a 2013 brochure:

Although many businesses have been outsourcing portions of their work for years now, out- sourcing is still becoming more popular by the day. This is especially driven by increased globalization, technological evolutions, and the need for standardised business processes. Out- sourcing is any task, operation, job, or process that could be performed by employees within the user organisation, but is instead contracted to a third party (service organisation) or another group company for a period of time.

Some examples for the financial sector are: � Asset managers that perform asset management services for different parties within the group company.

� Pension administrators who perform the administration for pension funds. � Claim service companies that perform claim handling services for large insurers.

The widespread use of outsourcing requires organizations to better manage their risks associated with the outsourced services. More specifically, the user organisation requires a degree of assurance that the service organisation has a well-established internal control framework that is operating effectively. New regulations, regulatory authorities and supervisory boards also ask for specific controls over outsourced procedures.51

Bosworth, S., Kabay, M. E., & Whyne, E. (Eds.). (2014). Computer security handbook, set. Retrieved from http://ebookcentral.proquest.com Created from apus on 2018-03-19 16:25:53.

C o p yr

ig h t ©

2 0 1 4 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

54 · 20 SECURITY AUDITS

54.4 SARBANES-OXLEY ACT

54.4.1 Introduction. This section focuses on the practicalities of SOX compli- ance in the real world and introduces concepts that the practitioner is sure to encounter.

Sarbanes-Oxley is the financial reporting act enacted into U.S. law in July 2002.52 It was the U.S. Government’s response to a number of major public-company accounting failures, including Enron53 and WorldCom.54

SOX is designed to reduce fraud and conflicts of interest while increasing financial transparency and public confidence in the market and in companies’ internal control systems. The act is intended to encourage honesty and integrity in financial reporting and to place responsibility directly with owners, managers, and executives. The act requires that the executive officers certify that they are “responsible for establishing and maintaining internal controls” and “have designed such internal controls to ensure that material information relating to the company and its consolidated subsidiaries is made known to such officers by others within those entities, particularly during the period in which the periodic reports are being prepared.” SOX allows for the possibility of both civil litigation and criminal prosecution.55 Thus, noncompliance is likely to result in fines, imprisonment, or both for those who fail to ensure the accuracy of their organization’s financial reporting.

Bearing in mind that SOX currently applies only to publicly traded companies with a market capitalization (or public debt) exceeding $75 million, many companies delisted themselves from U.S. stock exchanges or reverted to private status to avoid inclusion in the act.

More significantly, many non-U.S.-held companies now find themselves SOX- applicable because they or their subsidiaries are listed on the U.S. stock exchanges.56

Compliance is necessary for the entire organization, not just for the listed subsidiary. Thus, from humble beginnings, the act now has global market penetration.

SOX may originally have been the driver for complying with stricture regulations; however, in the decade since it was passed, “SOX compliance has moved beyond being just a regulatory obligation. Today it is viewed in the context of a larger Governance, Risk, and Compliance (GRC) program that is closely integrated with strategic decision- making, aligned with business goals, and enabled by technology.”57

It is in the best interests of an organization to design and implement a comprehensive governance program, to assess and implement internal processes and controls, and to set targets beyond that of mere regulatory compliance. The entire compliance effort should be repeatable, as compliance is not a one-off activity; rather it will be repeated annually for the life of the organization (or until such time as the law is materially revised or repealed).

54.4.2 Section 404. SOX consist of a number of sections; most are beyond the scope of this chapter. From an information assurance professional’s viewpoint however, Section 404 is the most significant and most widely discussed. It is the area that directly addresses the impact of information technology on financial reporting and the adequacy and effectiveness of associated internal controls.

Section 404 reads as follows:

SEC. 404. MANAGEMENT <<NOTE: 15 USC 7262.>> ASSESSMENT OF INTERNAL CONTROLS.

(a) Rules Required.–The Commission shall prescribe rules requiring each annual report re- quired by section 13(a) or 15(d) of the Securities Exchange Act of 1934 (15 USC 78m or 78o(d)) to contain an internal control report, which shall—

Bosworth, S., Kabay, M. E., & Whyne, E. (Eds.). (2014). Computer security handbook, set. Retrieved from http://ebookcentral.proquest.com Created from apus on 2018-03-19 16:25:53.

C o p yr

ig h t ©

2 0 1 4 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

SARBANES-OXLEY ACT 54 · 21

(1) state the responsibility of management for establishing and maintaining an adequate internal control structure and procedures for financial reporting; and

(2) contain an assessment, as of the end of the most recent fiscal year of the issuer, of the effectiveness of the internal control structure and procedures of the issuer for financial reporting.

(b) Internal Control Evaluation and Reporting.–With respect to the internal control assessment required by subsection (a), each registered public accounting firm that prepares or issues the audit report for the issuer shall attest to, and report on, the assessment made by the management of the issuer. An attestation made under this subsection shall be made in accordance with standards for attestation engagements issued or adopted by the Board. Any such attestation shall not be the subject of a separate engagement.

With widespread reliance on IT for financial and operational management systems, it is now accepted within U.S. industry that adequate and effective internal controls are necessary, particularly for systems supporting significant business processes.58

54.4.3 Achieving Compliance. SOX compliance should be approached by identifying key processes within the organization, documenting how they are imple- mented and controlled, and the defining or characterizing methods for reporting on their success or failure.

Coverage must include the entire system life cycle, and internal processes must include projects, design, architecture, system development, delivery, and operations. An auditor will be looking for no more than the assessment of core processes, the adequacy of associated controls, and whether those processes were followed, and controls executed, as stated. For more on SOX issues and regulations, see Chapter 64 in this Handbook.

54.4.3.1 Control Framework. Fortunately, the hard work of choosing a con- trols and assessment framework has already been done. The U.S. Securities and Ex- change Commission (SEC) mandates the use of the internal control framework rec- ommended by COSO,59 and the Public Company Accounting and Oversight Board (PCAOB)60 supports the SEC’s choice as detailed in its Auditing Standard No. 5, An Audit of Internal Control Over Financial Reporting Performed in Conjunction with an Audit of Financial Statements.61

54.4.3.2 COSO. The COSO “Internal Control—Integrated Framework (2013)”62 was sponsored by a consortium comprising:

� American Accounting Association (AAA) � American Institute of Certified Public Accountants (AICPA) � Financial Executives International (FEI) � Institute of Internal Auditors (IIA) � Institute of Management Accountants (IMA)

The Executive Summary discusses changes in the framework since the original 1992 version, including:

� Expectations for governance oversight � Globalization of markets and operations � Changes and greater complexities of business � Demands and complexities in laws, rules, regulations, and standards � Expectations for competencies and accountabilities

Bosworth, S., Kabay, M. E., & Whyne, E. (Eds.). (2014). Computer security handbook, set. Retrieved from http://ebookcentral.proquest.com Created from apus on 2018-03-19 16:25:53.

C o p yr

ig h t ©

2 0 1 4 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

54 · 22 SECURITY AUDITS

� Use of, and reliance on, evolving technologies � Expectations relating to preventing and detecting fraud.

According to COSO, “Internal control is a process, effected by an entity’s board of directors, management, and other personnel, designed to provide reasonable as- surance regarding the achievement of objectives relating to operations, reporting, and compliance.”

The Executive Summary continues:

This definition reflects certain fundamental concepts. Internal control is:

� Geared to the achievement of objectives in one or more categories—operations, reporting, and compliance

� A process consisting of ongoing tasks and activities—a means to an end, not an end in itself � Effected by people—not merely about policy and procedure manuals, systems, and forms, but about people and the actions they take at every level of an organization to affect internal control

� Able to provide reasonable assurance—but not absolute assurance, to an entity’s senior management and board of directors

� Adaptabletotheentitystructure—flexible in application for the entire entity or for a particular subsidiary, division, operating unit, or business process.

The “five integrated components” of internal control in the COSO framework can be summarized as follows:

� Control environment: “… [T]he set of standards, processes, and structures that provide the basis for carrying out internal controls across the organization. …”

� Risk assessment: Evaluation of probabilities for identified harmful events in the business context for the organization.

� Control activities: “[P]reventive or detective” actions taken to mitigate risks while achieving the corporate objectives.

� Information and communication: Organizations need current, accurate data about all aspects of operations, including monitoring for internal controls. “Commu- nication is the continual, iterative process of providing, sharing, and obtaining necessary information.”

� Monitoring activities: “Ongoing evaluations … provide timely information. Sep- arate evaluations, conducted periodically, will vary in scope and frequency de- pending on assessment of risks, effectiveness of ongoing evaluations, and other management considerations. Findings are evaluated against criteria established by regulators, recognized standard-setting bodies or management and the board of directors, and deficiencies are communicated to management and the board of directors as appropriate.”

54.4.3.3 COBIT. ISACA63 was originally called the Information Systems Audit and Control Association; ISACA defined a practical framework from which to derive key processes and controls for SOX compliance activities using its COBIT (Control Objectives for Information and Related Technology) framework. ISACA describes the principles underlying the framework as follows:

COBIT 5 is based on five key principles for governance and management of enterprise IT: � Principle 1: Meeting Stakeholder Needs � Principle 2: Covering the Enterprise End-to-End

Bosworth, S., Kabay, M. E., & Whyne, E. (Eds.). (2014). Computer security handbook, set. Retrieved from http://ebookcentral.proquest.com Created from apus on 2018-03-19 16:25:53.

C o p yr

ig h t ©

2 0 1 4 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

SARBANES-OXLEY ACT 54 · 23

� Principle 3: Applying a Single, Integrated Framework � Principle 4: Enabling a Holistic Approach � Principle 5: Separating Governance from Management

ISACA describes the benefits of COBIT 5 as follows:

COBIT 5 helps enterprises of all sizes:

� Maintain high-quality information to support business decisions � Achieve strategic goals and realize business benefits through the effective and innovative use of IT

� Achieve operational excellence through reliable, efficient application of technology � Maintain IT-related risk at an acceptable level � Optimize the cost of IT services and technology � Support compliance with relevant laws, regulations, contractual agreements and policies

The COBIT 5 framework describes seven categories of enablers:

1. Principles, policies, and frameworks are the vehicle to translate the desired be- havior into practical guidance for day-to-day management.

2. Processes describe an organized set of practices and activities to achieve certain objectives and produce a set of outputs in support of achieving overall IT-related goals.

3. Organizational structures are the key decision-making entities in an enterprise. 4. Culture, ethics, and behavior of individuals and of the enterprise are very often

underestimated as a success factor in governance and management activities.

5. Information is required for keeping the organization running and well governed, but at the operational level, information is very often the key product of the enterprise itself.

6. Services, infrastructure, and applications include the infrastructure, technology, and applications that provide the enterprise with information technology process- ing and services.

7. People, skills, and competencies are required for successful completion of all activities, and for making correct decisions and taking corrective actions.64

COBIT is a comprehensive framework for management of the governance of risk and control of IT, comprising four domains, 34 IT processes, and 215 control objectives.65

Although it has a wider purpose than simply addressing SOX compliance, COBIT removes much of the guesswork by suggesting 12 out of the 34 available standard processes for inclusion in a SOX implementation:

1. Acquire and maintain application software. (AI2) The provision of line of busi- ness applications, whether custom or off the shelf, should be congruent with business requirements.

2. Acquire and maintain technology infrastructure. (AI3) Technology infrastructure should underpin the delivery of services required by the business and follow organizational standards.

3. Enable operations. (AI4) Support effective use of technology through knowledge transfer, agreed service levels, and properly integrated solutions.

Bosworth, S., Kabay, M. E., & Whyne, E. (Eds.). (2014). Computer security handbook, set. Retrieved from http://ebookcentral.proquest.com Created from apus on 2018-03-19 16:25:53.

C o p yr

ig h t ©

2 0 1 4 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

54 · 24 SECURITY AUDITS

4. Install and accredit solutions and changes. (AI7) Ensure that supplied systems are fit-for-purpose prior to delivery and that they function as expected post- installation.

5. Manage changes. (AI6) Provide an effective, formal change management system to reduce errors and defects that may impact successful operations and business processes.

6. Define and manage service levels. (DS1) Align key business processes with delivery of technology in a set of meaningful service definition documents, with a mechanism for reporting to stakeholders on performance and achievement of service levels.

7. Manage third-party services. (DS2) Ensure the delivery of essential third-party services to support business activities while remaining transparent with regard to cost, benefits, and risks.

8. Ensure systems security. (DS5) Maximize the integrity and availability of systems and the confidentiality of data stored thereon while minimizing the impact of vulnerabilities through the application of effective security policies, standards, and procedures.

9. Manage the configuration. (DS9) Maintain an accurate and readily accessible repository of application and system configuration information, baseline stan- dards, and variations thereof.

10. Manage problems and incidents. (DS8, DS10) Provide formal problem and inci- dent management for all operations, including identification of issues, root cause analysis, and end-to-end problem resolution.

11. Manage data. (DS11) Provide tried and tested backup, recovery, and disposal systems.

12. Manage the physical environment and operations. (DS12) Control access to facilities and to computing assets, to reduce the likelihood of business disruption resulting from data leakage or theft of assets.

Specific analysis may require the addition of further processes, and within each process, the addition or removal of specific controls to further tailor the framework for each organization. Process and control selection must be agreed on in collaboration with the internal-audit function and with external auditors before committing to a particular framework.

54.4.3.4 Testing. Of equal importance to process and control selection is the agreement of the testing plan and schedule, especially the number of tests and the associated sample sizes.

For most organizations, resources are not unlimited. It is likely that staff will be asked to assume responsibility for some portion of SOX activity in addition to their regular workload. Thus, achieving a balance between compliance and the number of controls associated with each process is critical, because it is the controls that will be tested throughout the year, with the test results supporting the SOX certification process. A reduction in the number of tests or sample sizes can directly affect the integrity and quality of the results and positively affect staff efficiency and productivity. Although testing will likely be seen as onerous, much of the control activity should be considered business as usual, and thus the day-to-day processes should yield much of the evidence required for testing.

Bosworth, S., Kabay, M. E., & Whyne, E. (Eds.). (2014). Computer security handbook, set. Retrieved from http://ebookcentral.proquest.com Created from apus on 2018-03-19 16:25:53.

C o p yr

ig h t ©

2 0 1 4 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

SARBANES-OXLEY ACT 54 · 25

This section focuses on the importance and impact of IT on the wider goal of SOX compliance, but not all processes, even within an IT organization, are technical. Many are activities such as director-level meetings, incident boards, recovery forums, project risk meetings, and so on, and all may be part of a process that is included under SOX and must therefore be tested.

Testing typically falls into two categories: examination and discussion. Examination requires that a representative sample of evidence showing that a control is operating properly be collated and verified as accurate. Discussion requires that understanding of the process and associated controls be confirmed through one-to-one or group meetings among responsible staff. Sample sizes will depend on the test population and the frequency of sampling, and probably on the importance of the desired degree of accuracy and precision of the results for statistical confidence levels.

54.4.4 Audit and Certification. There will be at least two independent audit processes at work: internal and external. Internal audit will occur at the culmination of SOX testing, as a final quality-assurance checkpoint that the organization is compliant. Any identified gaps at must either be remediated or officially acknowledged within a formal risk process prior to the arrival of the external auditors.

54.4.4.1 External Audit. External audit will occur close to the end of the year and is the final test of compliance. It is not acceptable to wait until the external audit function identifies a gap before carrying out remediation activities. Any areas of noncompliance at this stage will be officially reported and may be included in the final management letter.

54.4.4.2 Schedule. Certification requirements vary by organization, although obviously at least an annual certificate will be required. Many organizations certify quarterly or monthly as part of some other SOX-related or controls process, and use those certificates to supplement their final annual declaration (see Exhibit 54.4).

54.4.5 Sarbanes-Oxley Conclusion. SOX compliance activities should not stand alone within the organization. They should be considered part of a wider risk- management program, preferably one supported by an embedded, proactive, risk-aware control culture. Further, it is never recommended to execute a compliance program with the goal of simply meeting regulatory requirements. In reality, a program that is designed from the outset to exceed the current regulation, and be adaptable to changes

EXHIBIT 54.4 Typical Annual SOX Schedule

Period* Activity

January/February Create and agree on controls and associated tests, certification schedule, and testing plan based on agreed processes

March to August Execute testing (typically by process) September Retest where necessary October Internal audit November/December External audit, produce certificates, publish management letter

*The actual dates for compliance activities will vary with each organization and its respective financial years and filing deadlines.

Bosworth, S., Kabay, M. E., & Whyne, E. (Eds.). (2014). Computer security handbook, set. Retrieved from http://ebookcentral.proquest.com Created from apus on 2018-03-19 16:25:53.

C o p yr

ig h t ©

2 0 1 4 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

54 · 26 SECURITY AUDITS

to existing or entirely new regulation, represents a much smarter investment of time and effort.

For additional discussion of SOX compliance, see Chapter 64 in this Handbook.

54.5 TECHNICAL FRAMEWORKS FOR IT AUDITS. The best IT auditors struggle with the reality of acceptable risk and vague controls, looking for solid frame- works to help with their audit. Great research and a good framework can help determine the questions for many of the unique or new audits that have not been faced in the past. Three useful models, as discussed next, can be applied from a high-level perspective to make sure that all of the relevant questions have been covered. In addition to models, general best practices help round out the technical bases to make sure the audit reveals any material weaknesses in key controls.

54.5.1 Framework 1: People, Processes, Tools, and Measures. The first useful framework—People, Processes, Tools, and Measures (PPTM)—is simple conceptually, but its wide scope digs quickly into often-overlooked critical processes and important controls. Take a randomly picked application about which nothing is known, and apply PPTM concepts to the application to understand it and to develop a series of controls to test, and useful information to gather.

1. People build the application, input data into the application, and use the output or storage of the data handled by the application. People are a component that touches or uses the application, and as such should have controls that govern the interaction. For example, how are the people authenticated or authorized as administrators or users of the application?

2. Processes surround the operations of the application. What processes govern standard operating practices, and how can they be validated?

3. Tools are the physical controls, such as other applications that might interface with the application or ensure the quality or validation of the application. Other types of tool controls include checking the platform that the application uses. What physical controls existed during the implementation or are currently in operations to make sure the application is in a secure environment?

4. Measures are often-overlooked metrics, although they represent some of the most useful data in thorough audits. They can verify that the application is performing its function in support of its assigned business role. For example, metrics can report on the operating efficiency of an application and how well it might scale to meet customer needs over time.

54.5.2 Framework 2: STRIDE. STRIDE, an acronym based on the ordered list of issues shown below, encompasses six areas of risk common to different tech- nologies. Much like PPTM, STRIDE will help in understanding how the area of risk might play a role in the technology to be audited and then in finding the controls that alleviate that risk. The keepers of the Open Web Application Security Project (OWASP, at www.owasp.com) provide an excellent example of applying STRIDE to Web applications.

1. S—Spoofing describes the risk of any user assuming the identity of another user or masking directly or indirectly the attributes of another user. For example, a user logging onto a banking Website should generally not be able to assume another user’s identity.

Bosworth, S., Kabay, M. E., & Whyne, E. (Eds.). (2014). Computer security handbook, set. Retrieved from http://ebookcentral.proquest.com Created from apus on 2018-03-19 16:25:53.

C o p yr

ig h t ©

2 0 1 4 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

TECHNICAL FRAMEWORKS FOR IT AUDITS 54 · 27

2. T—Tampering with data describes the need for input validation, process val- idation, and output validation. The integrity of the data should be preserved at all times, and in some cases protected from tampering, with encryption or by independent verification.

3. R—Repudiation describes a scenario where a user can suggest that a transaction never occurred. Poor audit trails lead to this situation. Nonrepudiation is the control that protects against repudiation. It includes signing a message with date and time as a unique, nonduplicatable moment.

4. I—Information disclosure describes the additional controls to prevent informa- tion from leaving the system to unauthorized parties or programs.

5. D—Denial of service describes a condition where the application or technology could be maliciously or inadvertently removed from service. If this is a concern, controls should be in place such as redundant systems, backups, and measures to prevent denial-of-service events.

6. E—Elevation of privilege describes the situation where a user maliciously or inadvertently gains administrative rights.

For a more complete model of the elements of computer security incidents, see Chapter 8 in this Handbook.

54.5.3 Framework 3: PDIO. PDIO—Plan, Design, Implement, and Opera- tions—borrows from Cisco System’s project management processes and describes the life cycle of a technology.66 This framework can be very powerful, especially when combined with PPTM.

Administrators address people, processes, tools, and measures at each step in a project’s planning, designing, implementation, and operations. PDIO can be viewed from a macroperspective to understand an entire new project or from a microperspective to understand each smaller element. The big-picture understanding of an audit is the mark of a great result that provides incredibly valuable—and useful—information to customers so that they can strengthen their controls.

54.5.4 General Best Practices. This short list of common best practices should help with additional controls for testing. This is especially helpful during an audit of a new technology that does not yet have an appropriate audit program.

1. Apply defense in depth so that you have layered controls. 2. Use a positive security model. By default, deny actions and allow only a trusted

or benign subset of available options. Negative security models trust everything by default and attempt to discover when to block offending behavior.

3. Fail safely so that people, equipment, data, and business processes are safe from harm.

4. Run with least privilege to prevent users from escalating their privileges above what is necessary to do their job.

5. Avoid security by obscurity. Try to hide data or options. Security by obscurity is setting up the technology for compromise.

6. Keep security simple. Overly complex systems are difficult to administer and often end up not secured.

Bosworth, S., Kabay, M. E., & Whyne, E. (Eds.). (2014). Computer security handbook, set. Retrieved from http://ebookcentral.proquest.com Created from apus on 2018-03-19 16:25:53.

C o p yr

ig h t ©

2 0 1 4 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

54 · 28 SECURITY AUDITS

7. Detect intrusions and keep logs. There should be an audit trail for everything important.

8. Never trust infrastructure and services, especially those coming from a third-party managed solution, where there might be different security policies and practices from the originating organization.

9. Establish secure defaults. Default to safe values and actions over defaulting to less secure values and actions. Another common mistake is not to specify an important value, causing issues later for the technology or application.

10. Use open standards because they are tested more thoroughly than proprietary technologies. Encryption in Digital Rights Management is an example where several purportedly secure private ciphers or cryptographic systems have been broken.

54.5.5 Technical Frameworks Conclusion. Frameworks can be valuable assets when approaching a technical audit, allowing quick determination of those areas where the audit is going to be most demanding and where compliance can be most effective.

54.6 FURTHER READING Brotby, W. K., and G. Hinson. PRAGMATIC Security Metrics: Applying Metametrics

to Information Security. Auerbach, 2013. Cascarino, R. E. Auditor’s Guide to IT Auditing, 2nd ed. Wiley, 2012. Chorafas, D. IT Auditing and Sarbanes-Oxley Compliance: Key Strategies for Business

Improvement. Auerbach, 2008. Cox, F. D. Information Security: Risk Management of GLBA Privacy and Service

Provider Oversight. Amazon Digital Services, 2011. Davis, C., M. Schiller, and K. Wheeler. IT Auditing Using Controls to Protect Infor-

mation Assets, 2nd ed. McGraw-Hill Osborne Media, 2011. Davis, R. E. IT Auditing: Assuring Information Assets Protection. Amazon Digital

Services, 2011. Halpert, B. Auditing Cloud Computing: A Security and Privacy Guide. Wiley, 2011. Hawker, A. Security and Control in Information Systems: A Guide for Business and

Accounting. Routledge, 2000. Hingarh, V., and A. Ahmed. Understanding and Conducting Information Systems

Auditing. Wiley, 2013. Moeller, R. R. IT Audit, Control, and Security. Wiley, 2012. Moeller, R. R. Executive’s Guide to IT Governance: Improving Systems Processes with

Service Management, COBIT, and ITIL. Wiley, 2013. Roebuck, K. Information Security Audit: High-Impact Strategies—What You Need to

Know: Definitions, Adoptions, Impact, Benefits, Maturity, Vendors. Lightning Source, 2011.

Senft, S., F. Gallegos, and A. Davis. Information Technology Control and Audit, 4th ed. Auerbach, 2012.

Weiss, M., and M. G. Solomon. Auditing IT Infrastructures for Compliance. Jones & Bartlett Learning, 2010.

Bosworth, S., Kabay, M. E., & Whyne, E. (Eds.). (2014). Computer security handbook, set. Retrieved from http://ebookcentral.proquest.com Created from apus on 2018-03-19 16:25:53.

C o p yr

ig h t ©

2 0 1 4 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

NOTES 54 · 29

54.7 NOTES 1. S. Abelow, “Five Ways that an IT Audit Adds Value.” Yahoo! Voices, January 13,

2011, http://voices.yahoo.com/five-ways-audit-adds-value-7567404.html 2. See, for example, “Guide for Assessing the Security Controls in Federal Informa-

tion Systems and Organizations” NIST Special Publication SP 800-53A Rev. 1 (June 2010), http://csrc.nist.gov/groups/SMA/fisma/assessment.html

3. U.S. Department of Defence CSC, “Rainbow Series” (1980), available at www.fas.org/irp/nsa/rainbow.htm

4. National Information Assurance Partnership (NIAP), www.niap-ccevs.org 5. Information Assurance Support Environment (IASE), STIGs: Security Technical Implementation Guides, U.S. Department of Defense (DoD) Defense Information Systems Agency (DISA), http://iase.disa.mil/stigs

6. Computer Security Resource Center (CSRC) Special Publications (800 Series), National Institute of Standards and Technology (NIST) Information Technology Laboratory (ITL), http://csrc.nist.gov/publications/PubsSPs.html

7. Information Technology Infrastructure Library (ITIL), www.itil-officialsite.com 8. ISO is not an abbreviation of International Organization for Standardization but

instead a shortened form of the Greek isos, meaning equal. The term was chosen to be understood in all translations and speak to the organization’s intent of equal representation for all members regardless of their national economic status or country’s level of development.

9. U.S. Senate Committee on Banking, Housing and Urban Affairs, Financial Services Modernization Act (1999), http://banking.senate.gov/conf/grmleach.htm

10. NIST, “Federal Information Security Management Act (FISMA) Implementation Project,” http://csrc.nist.gov/groups/SMA/fisma/index.html

11. Federal Information Security Management Act of 2002 (FISMA), 44 USC 3541, et seq., www.law.cornell.edu/uscode/text/44/3541

12. OMB, Circular A-130—Revised, Transmittal Memorandum No. 4, “Memoran- dum for Heads of Executive Departments and Agencies; Subject: Management of Federal Information Resources,” www.whitehouse.gov/omb/circulars/a130/ a130trans4.html

13. NIST, “FISMA Risk Management Framework,” http://csrc.nist.gov/groups/ SMA/fisma/framework.html

14. NIST, “FISMA Detailed Overview,” http://csrc.nist.gov/groups/SMA/fisma/ overview.html

15. Health Information Privacy, U.S. Department of Health & Human Services (HHS), www.hhs.gov/ocr/privacy

16. HIPAA, www.gpo.gov/fdsys/pkg/PLAW-104publ191/html/PLAW-104publ191 .htm

17. PCI Security Standards Council—About Us, https://www.pcisecuritystandards. org/organization info/index.php

18. “PCI DSS Quick Reference Guide,” https://www.pcisecuritystandards.org/ documents/PCI%20SSC%20Quick%20Reference%20Guide.pdf

19. PCI Security Standards Council—Documents Library, https://www.pcisecurity standards.org/security standards/documents.php?document=pci dss v2-0#pci dss v2-0

Bosworth, S., Kabay, M. E., & Whyne, E. (Eds.). (2014). Computer security handbook, set. Retrieved from http://ebookcentral.proquest.com Created from apus on 2018-03-19 16:25:53.

C o p yr

ig h t ©

2 0 1 4 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

54 · 30 SECURITY AUDITS

20. NIST, “Recommended Security Controls for Federal Information Systems,” Special Publication 800-53 Revision 4 (April 2013), http://dx.doi.org/10.6028/ NIST.SP.800-53r4

21. NIST, “Standards for Security Categorization of Federal Information and In- formation Systems (February 2004),” FIPS 199, http://csrc.nist.gov/publications/ fips/fips199/FIPS-PUB-199-final.pdf

22. A federal information system is an information system used or operated by an executive agency, by a contractor of an executive agency, or by another organization on behalf of an executive agency.

23. NIST, “Guideline for Identifying an Information System as a National Security Sys- tem (August 2004),” Special Publication 800-59, http://csrc.nist.gov/publications/ nistpubs/800-59/SP800-59.pdf

24. NIST, “Minimum Security Requirements for Federal Information and In- formation Systems (March 2006),” FIPS-200, http://csrc.nist.gov/publications/ fips/fips200/FIPS-200-final-march.pdf

25. NIST, “Federal Information Security Management Act (FISMA) Implementation Project,” http://csrc.nist.gov/groups/SMA/fisma/index.html

26. NIST, “Draft Guide for Mapping Types of Information and Information Sys- tems to Security Categories: Volume 1: Guide for Mapping Types of Infor- mation and Information Systems to Security Categories; Volume 2: Appen- dices,” SP 800-60 Revision 1. http://csrc.nist.gov/publications/nistpubs/800-60- rev1/SP800-60 Vol1-Rev1.pdf and http://csrc.nist.gov/publications/nistpubs/800- 60-rev1/SP800-60 Vol2-Rev1.pdf

27. NIST, “Risk Management Guide for Information Technology Systems (Sept 2012),” SP 800-30 Revision 1, http://csrc.nist.gov/publications/nistpubs/800-30- rev1/sp800 30 r1.pdf

28. NIST, “Guide for Developing Security Plans for Federal Information Systems (February 2006),” SP 800-18 Revision 1, http://csrc.nist.gov/publications/nistpubs/ 800-18-Rev1/sp800-18-Rev1-final.pdf

29. NIST, “Security and Privacy Controls for Federal Information Systems and Organizations,” SP 800-53 Revision 4 (May 2013), http://dx.doi.org/10.6028/ NIST.SP.800-53r4

30. NIST, “Guide for Applying the Risk Management Framework to Federal Informa- tion Systems: A Security Life Cycle Approach,” SP 800-37 Revision 1 (Feb 2010). http://csrc.nist.gov/publications/nistpubs/800-37-rev1/sp800-37-rev1-final.pdf

31. NIST SP 800-37 and SP 800-53A (see previous notes). 32. See endnote 1. 33. For membership information, contact the Head of Membership, listed on the “Struc-

ture and governance page,” www.iso.org/iso/home/about/about governance.htm 34. All approved standards continue to be subject to periodic review to ensure timely

update of industry requirements and technologies. 35. International Organization for Standardization, Standards FAQ. www.iso.org/

iso/home/faqs/faqs standards.htm 36. An ISMS includes any components necessary to maintain information assurance,

including policies, plans, processes, roles, responsibilities, and so forth. 37. ISO/IEC 17799:2005 (superseded by ISO/IEC 27002:2005), www.iso.org/iso/

home/store/catalogue ics/catalogue detail ics.htm?csnumber=39612

Bosworth, S., Kabay, M. E., & Whyne, E. (Eds.). (2014). Computer security handbook, set. Retrieved from http://ebookcentral.proquest.com Created from apus on 2018-03-19 16:25:53.

C o p yr

ig h t ©

2 0 1 4 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

NOTES 54 · 31

38. International Organization for Standardization, “Improved ISO/IEC 17799 Makes Information Assets Even More Secure,” www.iso.org/iso/home/news index/news archive/news.htm?refid=Ref963

39. ISO/IEC 27000:2012, http://standards.iso.org/ittf/PubliclyAvailableStandards/ c056891 ISO IEC 27000 2012(E).zip

40. Effective April 2007, ISO 17799 was superseded by ISO/IEC 27002. 41. OECD is an international cooperative committed to sharing information and devel-

oping accepted standards on economic and social issues related to trade, education, development, and science: www.oecd.org

42. IT Governance Ltd., “ISO 27001 & Information Security,” www.itgovernance .co.uk/iso27001.aspx

43. IT Governance Ltd., Information Security & ISO 27001: An Introduction, www.itgovernance.co.uk/everything-you-want-and-need-for-iso27001.aspx

44. IT Governance Ltd., ISO 27001 in North America, www.itgovernance.co.uk/shop/ p-1243-it-regulatory-compliance-in-north-america.aspx#.Udnt4UvDnsY

45. “Extended Mass Layoffs in 2011.” Report 1039, U.S. Department of Labor and U.S. Bureau of Labor Statistics December 2012, www.bls.gov/mls/mlsreport1039.pdf (calculations based on data from Table 13, page 16).

46. C. Isidore, “Uncle Sam’s outsourcing tab: $517 billion,” CNNMoney June 10, 2013, http://money.cnn.com/2013/06/10/news/economy/outsourced-federal- government/index.html

47. AICPA, “SAS 70 Overview,” http://sas70.com/sas70 overview.html 48. AICPA, “SSAE Overview,” http://ssae16.com/SSAE16 overview.html 49. “Treadway” refers to the founding Chairman of the Commission, James C. Tread-

way, Jr. For a history and further details of COSO, see their “About” Web page: http://coso.org/aboutus.htm

50. AICPA, “ISAE 3402 Overview,” http://isae3402.com/ISAE3402 overview.html 51. Ernst & Young, “Implementing and maintaining ISAE 3402” (2013). 52. Pub. L. 107-204, July 30, 2002, 116 Stat. 745; see Legal Information Institute entry

for 15 USC 7201 ff, www.law.cornell.edu/topn/sarbanes-oxley act of 2002 53. M. Jickling, “The Enron Collapse: An Overview of Financial Issues.” Congres-

sional Research Service Report RS21135, February 4, 2002, http://fpc.state.gov/ documents/organization/8038.pdf

54. M. Jickling, “Accounting Problems Reported in Major Companies Since Enron.” Congressional Research Service Report RS21269, January 2002, http://congressionalresearch.com/RS21269/document.php

55. 15 USC 7241 (Section 302) (civil provision), www.law.cornell.edu/uscode/text/ 15/7241 and 18 USC 1350 (Section 906) (criminal provision), www.law.cornell .edu/uscode/text/18/1350

56. World Stock Exchanges, www.world-stock-exchanges.net/usa.html 57. MetricStream, “Ten Years On, Approach to SOX Shifts from Compliance to Better

Governance,” press release, July 24, 2012, www.metricstream.com/pressNews/ pr 385 Ten-years-sox.html

58. A significant business process is one that accounts for a minimum portion of an organization’s balance sheet. The actual threshold for inclusion will vary by organization.

Bosworth, S., Kabay, M. E., & Whyne, E. (Eds.). (2014). Computer security handbook, set. Retrieved from http://ebookcentral.proquest.com Created from apus on 2018-03-19 16:25:53.

C o p yr

ig h t ©

2 0 1 4 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

54 · 32 SECURITY AUDITS

59. Committee of the Sponsoring Organizations of the Treadway Commission, www.coso.org

60. Public Company Accounting Oversight Board (PCAOB). http://pcaobus.org/ Pages/default.aspx

61. PCAOB Auditing Standard No. 5 superseded Auditing Standard No. 2 as of 15 November 2007. http://pcaobus.org/Standards/Auditing/Pages/Auditing Standard 5.aspx

62. “Internal Control—Integrated Framework (2013),” COSO, May 2013. Avail- able from “Guidance on Internal Control” page: http://coso.org/IC.htm with Executive Summary available at http://coso.org/documents/990025P Executive Summary final may20 e.pdf

63. History of ISACA, www.isaca.org/About-ISACA/History/Pages/default.aspx 64. COBIT 5, www.isaca.org/COBIT/Pages/default.aspx 65. COBIT documents in PDF are available to members and nonmembers of ISACA

for free; printed copies are available at low cost (e.g., $50 for nonmembers and $35 for members). At the time of writing in July 2013, versions were available in Chinese, French, Spanish, and German, with other language translations under development. www.isaca.org/COBIT/Pages/Product-Family.aspx

66. As of the time of writing (July 2013), there were two dozen hits for the search on “PDIO” at the CISCO Website, http://tinyurl.com/l8fkvb6

Bosworth, S., Kabay, M. E., & Whyne, E. (Eds.). (2014). Computer security handbook, set. Retrieved from http://ebookcentral.proquest.com Created from apus on 2018-03-19 16:25:53.

C o p yr

ig h t ©

2 0 1 4 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

55CHAPTER

CYBER INVESTIGATION1

Peter Stephenson

55.1 INTRODUCTION 55 · 1 55.1.1 Defining Cyber

Investigation 55·2 55.1.2 Distinguishing between

Cyber Forensics and Cyber Investigation 55·2

55.1.3 DFRWS Framework Classes 55·2

55.2 END-TO-END DIGITAL INVESTIGATION 55 · 9 55.2.1 Collecting Evidence 55·10 55.2.2 Analysis of

Individual Events 55·10 55.2.3 Preliminary

Correlation 55·11 55.2.4 Event Normalizing 55·11 55.2.5 Event Deconfliction 55·11 55.2.6 Second-Level

Correlation 55·11 55.2.7 Timeline Analysis 55·12 55.2.8 Chain of Evidence

Construction 55·12 55.2.9 Corroboration 55·12

55.3 APPLYING THE FRAMEWORK AND EEDI 55 · 12

55.3.1 Supporting the EEDI Process 55·12

55.3.2 Investigative Narrative 55·13

55.3.3 Intrusion Process 55·13 55.3.4 Describing Attacks 55·14 55.3.5 Strategic Campaigns 55·15

55.4 USING EEDI AND THE FRAMEWORK 55 · 16

55.5 MOTIVE, MEANS, AND OPPORTUNITY: PROFILING ATTACKERS 55 · 17 55.5.1 Motive 55·18 55.5.2 Means 55·20 55.5.3 Opportunity 55·20

55.6 SOME USEFUL TOOLS 55 · 21 55.6.1 Link Analysis 55·22 55.6.2 Attack-Tree Analysis 55·24 55.6.3 Modeling 55·24

55.7 CONCLUDING REMARKS 55 · 25

55.8 FURTHER READING 55 · 25

55.9 NOTES 55 · 26

55.1 INTRODUCTION. Cyber investigation (also widely known as digital inves- tigation) as a discipline has changed markedly in the first two decades of the twenty-first century. In 1999, when Investigating Computer Related Crime2 was published, prac- titioners in the field were just beginning to speculate as to how cyber investigations would be carried out. At that time, the idea of cyber investigation was almost com- pletely congruent with the practice of computer forensics. Today (as this is being edited in July 2013), we know that such a view is too confining for investigations in the current digital environment.

55 · 1 Bosworth, S., Kabay, M. E., & Whyne, E. (Eds.). (2014). Computer security handbook, set. Retrieved from http://ebookcentral.proquest.com Created from apus on 2018-03-19 16:25:53.

C o p yr

ig h t ©

2 0 1 4 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

55 · 2 CYBER INVESTIGATION

Cyber investigation today is evolving into a discipline that is not only becoming commonplace in information technology but is also finding acceptance by both law enforcement and the forensic science community. The American Academy of Forensic Science, for example, now recognizes the forensic computer-related crime investigator as a legitimate discipline within its general category of membership.3

This chapter defines cyber investigation and examines some of its forensic com- ponents. It discusses a useful cyber investigation approach called end-to-end digital investigation (EEDI). Finally, the chapter explores some forensic tools and considers their usefulness both practically and theoretically.

55.1.1 Defining Cyber Investigation. Rogers, Brinson, and Robinson4 ap- proach the definition of cyber forensics in an ontology (“the question of how many fundamentally distinct sorts of entities compose the universe”5); it can also be viewed as a taxonomy (“the practice or principles of classification”6). Although their descriptive schema is not complete, it is informative. Most important, Rogers’s approach recog- nizes that there is no simple definition of cyber investigation; ontology and taxonomy are therefore particularly useful in clarifying meaning and structure for such a field.

The Rogers cyber forensic ontology consists of five layers. Ontology generally con- tains classes, subclasses, slots, and instances. These elements also contain constraints and relations. Rogers’s five layers can be considered to be a superclass with two classes and four nested subclasses. He does not define the other elements in his paper. The Rogers schema is easy to extend, however, to a proper ontology using a tool such as Protégé.7 For our purposes, we will refer to his model as the Rogers taxonomy.

The core of the Rogers taxonomy as a definition resides in the relationships inherent in the various subclasses. Exhibit 55.1 presents the taxonomy as a hierarchy with two major classes, Profession and Technology.

Starting with cyber forensics at the top and with two classes represented in columns, the farther to the right in each class, the more granularity one adds to the character- ization. Ontology supports understanding by providing a collection of characteristics that describe a concept; each class and nested subclass adds characteristics to that concept and contributes to a functional definition of cyber forensics. At the same time, concepts not included help to constrain the description and increase the precision of the ontological definition.

55.1.2 Distinguishing between Cyber Forensics and Cyber Investiga- tion. Cyber investigation uses the tools of cyber forensics as part of investigative procedures. The Digital Forensics Research Workshop (DFRWS)8 in 2001 developed a useful framework for digital investigation,9 a version of which appears in Exhibit 55.2.

Although this framework appeared in 2001, it has not been improved on markedly in the intervening years.10

55.1.3 DFRWS Framework Classes. The DFRWS framework is a matrix. The columns are calledclassesand the cells are calledelements. In the class descriptions that follow, the quoted italicized descriptions are taken verbatim from the original publication.11

The DFRWS framework classes contain key elements that are under constant review by the digital forensics community. The continuity among the classes is important; for example, the Preservation class continues as an element of the Collection, Examination, and Analysis classes. This indicates that preservation of evidence (as characterized by case management, imaging technologies, chain of custody, and time synchronization)

Bosworth, S., Kabay, M. E., & Whyne, E. (Eds.). (2014). Computer security handbook, set. Retrieved from http://ebookcentral.proquest.com Created from apus on 2018-03-19 16:25:53.

C o p yr

ig h t ©

2 0 1 4 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

INTRODUCTION 55 · 3

Profession

Law

Academia

Enforcement

Evidence

Collection/Analysis

Discipline definition

Problem solving

Professional outcome

Contributions

Passive

Proactive

Reactive

System admins

Legal contact

Expert witness consultant

Forensic analysis

Data recovery

Active

Courts

Research

Education

Offensive

Defensive

Industry

Military

Private sector

Consulting

Laws

People

Technology

Software

Analysis tools

Proprietary

Open-source tools

Operating systems

Proprietary OS

Open-source OS

Open source

File systems

Windows

UNIX/Linux

Mac

Hardware

Large-scale digital devices

Clusters

Grids

Small-scale digital devices

Cell phones

PDAa

SSD Operating software

Computers

Desktops

Laptops

Servers

Tablets

Storage devices

Thumb drive

Digital music player

External music player

External hard drives

Obscure devices

Gaming devices

Recording devices

EXHIBIT 55.1 Rogers Cyber Forensics Taxonomy

is an ongoing requirement throughout the digital investigative process. Thus, preser- vation is “a guarded principle across ‘forensic’ categories.”12 Traceability, likewise, is a guarded principle, but not across all forensic categories. The next topics discuss each of the DFRWS framework classes in more detail. Elements marked with an asterisk (∗) in the discussions are required in all cyber investigations.

55.1.3.1 Identification Class. The DFRWS defines the Identification class in this way:

Determining items, components, and data possibly associated with the allegation or incident. Perhaps employing triage techniques.13

The Identification class describes the method by which the investigator is notified of a possible incident. Since about 50 percent of all reported incidents have benign

Bosworth, S., Kabay, M. E., & Whyne, E. (Eds.). (2014). Computer security handbook, set. Retrieved from http://ebookcentral.proquest.com Created from apus on 2018-03-19 16:25:53.

C o p yr

ig h t ©

2 0 1 4 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

EX H IB

IT 5 5 .2

D FR

W S D ig ita

lI nv es tig

at io n Fr am

ew or k

Id e n ti fi ca

ti o n

P re

se rv

a ti o n

C o ll e ct io n

Ex a m in a ti o n

A n a ly si s

P re

se n ta

ti o n

Ev en

t/ C ri m e de

te ct io n

C as e m an

ag em

en t

Pr es er va

tio n

Pr es er va

tio n

Pr es er va

tio n

D oc

um en

ta tio

n Re

so lv e si gn

at ur e

Im ag

in g te ch

no lo gi es

A pp

ro ve d m et ho

ds Tr ac

ea bi lit y

Tr ac

ea bi lit y

Ex pe

rt te st im

on y

Pr ofi

le de

te ct io n

C ha

in of

cu st od

y A pp

ro ve d so ftw

ar e

Va lid

at io n te ch

ni qu

es St at is tic al

C la ri fic at io n

A no

m al ou

s de

te ct io n

Ti m e sy nc

hr on

iz at io n

A pp

ro ve d ha

rd w ar e

Fi lte ri ng

te ch

ni qu

es Pr ot oc

ol s

M is si on

im pa

ct st at em

en t

C om

pl ai nt s

Le ga

la ut ho

ri ty

Pa tte rn

m at ch

in g

D at a m in in g

Re co

m m en

de d co

un te rm

ea su re

Sy st em

m on

ito ri ng

Lo ss le ss

co m pr es si on

H id de

n da

ta di sc ov

er y

Ti m el in e

St at is tic al

in te rp re ta tio

n A ud

it an

al ys is

Sa m pl in g

H id de

n da

ta ex

tra ct io n

Li nk

D at a re du

ct io n

Sp at ia l

Re co

ve ry

te ch

ni qu

es

55 · 4 Bosworth, S., Kabay, M. E., & Whyne, E. (Eds.). (2014). Computer security handbook, set. Retrieved from http://ebookcentral.proquest.com Created from apus on 2018-03-19 16:25:53.

C o p yr

ig h t ©

2 0 1 4 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

INTRODUCTION 55 · 5

explanations,14 processing evidence in this class is critical to the rest of the investigation. Likewise, as it is the first step in the EEDI process, it is the only primary evidence not corroborated directly by other primary evidence. Therefore, a more significant amount of secondary evidence is needed to validate the existence of an actual event.

The author has adopted the next definitions of the individual framework classes for the purposes of EEDI. The DFRWS has, as of this writing, not developed such definitions. Elements marked with an asterisk (∗) are required elements within the DFRWS class. The elements of the Identification class are:

� Event/crime detection.∗ This element implies direct evidence of an event. An example of such direct evidence is discovery that a large number of credit card numbers have been downloaded from a server.

� Resolve signature. This applies to the use of some automated event detection system, such as an intrusion system or anti-virus software program. The system in use must make its determination (of the presence of an event of interest) by means of signature analysis and mapping.

� Profile detection. Like signature resolution, profile detection usually relies on some automated event detection system. However, in this instance, the event will be characterized through matching with a particular profile as opposed to an explicit signature. Signatures generally apply to an individual event. Events, however, may come together in an attack scenario or attack profile. Such a profile may consist of a number of events, a pattern of behavior, or pattern of specific results of an attack.

� Anomalous detection. Again, like the preceding two elements, this usually relies on a detection system. However, in the case of anomalous detection, the event is deduced from the detection of patterns of behavior outside of the observed norm. Anomalies can include the presence of unusual behavior but also, as in the classic Sherlock Holmes case of the dog that “did nothing in the night-time,” the absence of expected behavior.15

� Complaints. This element relies on the direct reporting of a potential event by an observer. This person may observe the event directly or simply the end result of the event.

� System monitoring. System monitoring explicitly requires some sort of intrusion detection, anti-virus, or similar system in place. It is less specific than other elements requiring a specific action (e.g., anomaly, profile of signature detection) and may be used together with another element of this class.

� Audit analysis. This element refers particularly to the analysis of various audit logs produced by source, target, and intermediate devices.

55.1.3.2 Preservation Class. The Preservation class deals with those ele- ments that relate to the management of items of evidence. The DFRWS describes this class as “a guarded principle across ‘forensic’ categories.” The requirement for proper evidence handing is basic to the digital investigative process as it relates to legal actions.

The DFRWS defines this class as “[e]nsuring evidence integrity or state.”

� Case management.∗ This element covers the management of the investigative process by investigators and digital forensic examiners. Typical in this element are investigator notes, process controls, quality controls, and procedural issues.

Bosworth, S., Kabay, M. E., & Whyne, E. (Eds.). (2014). Computer security handbook, set. Retrieved from http://ebookcentral.proquest.com Created from apus on 2018-03-19 16:25:53.

C o p yr

ig h t ©

2 0 1 4 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

55 · 6 CYBER INVESTIGATION

� Imaging technologies. This element is separate from the elements in the Collec- tion class, in that it does not refer to specific hardware, software, or techniques. The imaging technologies element refers to the technology used for imaging computer media. For example, physical imaging or bitstream backup may be considered an appropriate imaging technology whereas a logical backup would not be. The term imaging as used here is rather broad. It encompasses not only the technology used to create an image of computer media but also the technology used to extract such items as logs from a device. In this case, the log might be extracted from a bitstream image or it might be read out of the device to a peripheral as a result of a keystroke command issued by the investigator.

� Chain of custody.∗ This element refers to the process of limiting access to and subsequent alteration of evidence. In most jurisdictions chain of custody rules require that the evidence custodian be able to account for all accesses or possible accesses to items of evidence within his or her care from the time it is collected until the time it is used in a legal proceeding,

� Time synchronization.∗ This element refers to the synchronizing of evidence items to a common time base. Since logs and other evidence are collected from a number of devices during the conduct of an investigation, it is clear that those devices can differ from each other in terms of time base. If all devices are in a single time-synchronized network, they will not, of course, differ. However, that rarely is the case, and some effort must be made to obtain a common time base for all devices. There are two approaches one might take. The first is to adjust all times on evidence to a common device. The second is to use a common time zone (TZ), such as Universal Time (UT) or Greenwich Mean Time (GMT), as a baseline. No evidence is modified. The investigator simply notes the variance of a particular log or other piece of digital evidence from the predetermined time standard. This also is referred as normalizing time stamps.

55.1.3.3 Collection Class. The Collection class is concerned with the specific methods and products used by the investigator and forensic examiner to acquire evi- dence in a digital environment. As has been noted, the Preservation class continues as an element of this class. With the exception of the legal authority element, the elements of this class are largely technical.

The DFRWS defines this class as “[e]xtracting or harvesting individual items or groupings.”

� Approved methods.∗ This element refers to the techniques used by the forensic examiner or investigator to extract digital evidence. The concept of being ap- proved refers to the general acceptance in courts of the techniques and training or certifications of the individual performing the evidence collection. The most rigorous test of methods and technologies is the Daubert test. (For more informa- tion on expert testimony, see Chapter 73 in this Handbook.) However, due largely to the immaturity of digital forensic science, most court tests have not had this level of rigor applied. For this reason, those elements in this class that relate to approval derive their authority from cases where the technique, technology, or product has been challenged in a court of the same level as the case in question and has survived the test.

� Approved software. This element addresses the specific software product used to collect evidence. The discussion of the approval process in the last bullet point

Bosworth, S., Kabay, M. E., & Whyne, E. (Eds.). (2014). Computer security handbook, set. Retrieved from http://ebookcentral.proquest.com Created from apus on 2018-03-19 16:25:53.

C o p yr

ig h t ©

2 0 1 4 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

INTRODUCTION 55 · 7

applies. There is an issue specifically involving software used for digital forensic data collection. In order for a software program to be considered approved, it must be identical in every way to the software that has survived either a Daubert hearing or a court challenge. That means that the software source code must be in every way identical in both instances of the program. Failing that, the program may need to undergo its own court testing. For the purposes of the framework and subsequent EEDI procedures, however, a program that has any differences (e.g., version level, bug fixes, source code changes, etc.) from the program tested originally is not considered to be approved software.

� Approved hardware. This element describes the hardware, if any, used to collect evidence. Usually this is not an issue unless the hardware is designed specifically for use in a digital forensic evidence collection environment. To a lesser extent, the caveats of sameness that apply to approved software apply to approved hardware. The hardware device used must in every way be identical to instances of the device that have survived court challenges. The approved hardware element does not apply to simple computers, disks, or other media used by the examiner to collect evidence unless the device was developed explicitly for digital forensic evidence collection and contains special unique features for use in that environment only.

� Legal authority.∗ The legal authority element is the only element of this class that is nontechnical. In most jurisdictions, some legal authority is required prior to extracting information from computer media. This authority could be a policy, a subpoena, or a search warrant, for example. Failure to comply with applicable laws may render the evidence collected useless in a court of law.

� Lossless compression. This element refers to the compression techniques, if any, used by backup, encryption, or digital signature software used to collect and/or preserve evidence. If the software program uses compression, it must be proven to be lossless, that is, to cause no change whatever upon the integrity of the evidence on which it is used.

� Sampling. If sampling techniques are used to collect evidence, it must be shown that the technique causes no degradation of the evidence collected, or, if it has, that the effects can be demonstrated clearly and unambiguously. It must also be shown that the sampling method is valid (generally accepted by the mathematical community) and that the conclusions that may be drawn from the sample are defined clearly.

� Data reduction. When techniques and/or programs (such as normalization) are used to reduce data that contain or may contain evidence, it must be shown that such techniques or programs produce valid, repeatable, provable results that do not affect, in any way whatever, the evidence being collected. For example, using data reduction directly on evidence would alter the evidence and would not be acceptable. However, using such methods or tools on a copy of the evidence would have no direct affect on the evidence. Its affect on the analysis of the evidence (the validity of conclusions, for example) is an issue for the Examination and Analysis classes.

� Recovery techniques. This element refers to the recovery of data that may contain evidence from a digital device. It specifically describes the methods used by the forensic examiner to extract evidence using approved hardware, software, and methods. Whereas the elements of approved hardware, software, and methods refer to the naming (or brief description of) the element and the connection

Bosworth, S., Kabay, M. E., & Whyne, E. (Eds.). (2014). Computer security handbook, set. Retrieved from http://ebookcentral.proquest.com Created from apus on 2018-03-19 16:25:53.

C o p yr

ig h t ©

2 0 1 4 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

55 · 8 CYBER INVESTIGATION

between the element and the appropriate court test by which it is approved, recovery techniques describes in detail the actual process used to recover the evidence. By extension, when nonforensic methods are used to collect information (e.g., traditional investigation methods such as interviewing), we consider these techniques also to be recovery techniques and we apply the same rules to them (e.g., approved methods, legal authority, etc.) as we would in a digital environment. However, we apply the rules in the context of the technique used.

55.1.3.4 Examination Class. The Examination class deals with the tools and techniques used to examine evidence. The DFRWS gives describes the Examination class in this way: “Closer scrutiny of items and their attributes (characteristics).” It is concerned with evidence discovery and extraction rather than the conclusions to be drawn from the evidence (Analysis class). Whereas the Collection class deals with gross procedures to collect data that may contain evidence (such as imaging of computer media), the Examination class is concerned with the examination of those data and the identification and extraction of possible evidence from them. Note that the Preservation class continues to be pervasive in the Examination class.

� Traceability.∗ This element is, arguably, the most important element in the EEDI process. It is the traceability and continuity of a chain of evidence throughout an investigation that leads to the credibility and correctness of the conclusions. According to the DFRWS, “[t]raceability (cross referencing and linking) is key as evidence unfolds.”

� Validation techniques. This element refers to techniques used to corroborate evidence. Evidence may be corroborated in a variety of ways. Traditionally, evi- dence is corroborated by other, relevant evidence. However, digital evidence may stand on its own merit if its technical validity can be established. For example, a fragment of text extracted from an image of a computer disk may be shown to be a valid piece of evidence through various technical validation techniques. Its applicability or usefulness as an element of proof in an investigation may be open to interpretation, but that it is valid data would not be in dispute. A log, however, if extracted from a device that had been penetrated by a criminal hacker, would require additional corroboration (validation) to show that the hacker had not altered its contents.

� Filtering techniques. When dealing with evidence acquired from certain types of digital systems (such as intrusion detection systems), it is not uncommon to find that the gross data have been filtered for expediency by the system. Although many intrusion detection experts would agree that filtering at the source (the incoming data flow from sensors) is not as appropriate as filtering the display while preserving the original data, such source filtering does occur. This element requires that the investigator and/or forensic examiner determine and describe the filtering techniques used, if any, and apply the results of that description to the determination of the validity of the data as evidence. Another application of filtering is the extraction of potential evidence from a gross data collection16 such as a bit-stream image of digital media. Some digital forensic tools use filters to extract data of a particular type, such as graphical images. This element requires that the filtering technique be defined clearly and understood by the investigator or forensic examiner. These tools may also use the filtering technique of matching a known hash value to digital items on a gross data collection. Items that match

Bosworth, S., Kabay, M. E., & Whyne, E. (Eds.). (2014). Computer security handbook, set. Retrieved from http://ebookcentral.proquest.com Created from apus on 2018-03-19 16:25:53.

C o p yr

ig h t ©

2 0 1 4 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

END-TO-END DIGITAL INVESTIGATION 55 · 9

the known hash are presumed to be the same as the item for which the hash value was originally generated. Again, the techniques and tools applied must be clearly understood by the investigator or the forensic examiner.

� Pattern matching. This element addresses methods used to identify potential events by some predetermined signature or pattern. Examples are pattern-based intrusion detection systems and signature-based virus checkers. When the pat- tern or signature is unclear, ambiguous, or demonstrates a large number of false positives or negatives, the evidence and conclusion following from it are open to challenge.

� Hidden data discovery. This element refers to the discovery of evidence that is hidden in some manner on computer media. The data may be hidden using encryption, steganography, or any other data-hiding technique. It may also include data that have been deleted but are forensically recoverable.

� Hidden data extraction. This element addresses the extraction of hidden evidence from a gross data collection.

55.1.3.5 Analysis Class. This class is described by the DFRWS as “[f]usion, correlation and assimilation of material for reasoned conclusions.”

The Analysis class refers to those elements that are involved in the analysis of evi- dence collected, identified, and extracted from a gross data collection. The validity of techniques used in analysis of potential evidence impact as directly the validity of the conclusions drawn from the evidence and the credibility of the evidence chain con- structed therefrom. The Analysis class contains, and is dependent on, the Preservation class and the Traceability element of the Examination class.

The various elements of the Analysis class refer to the means by which a foren- sic examiner or investigator might develop a set of conclusions regarding evidence presented from the other five classes. As with all elements of the framework, a clear understanding of the applicable process is required. Wherever possible, adherence to standard tools, technologies, and techniques is critical.

The link element is the key element used to form a chain of evidence. It is related to traceability and, as such, is a required element.

55.1.3.6 Presentation Class. DFRWS describes the Presentation class in this way: “Reporting facts in an organized, clear, concise, and objective manner.”

This class refers to the tools and techniques used to present the conclusions of the investigator and the digital forensic examiner to a court of inquiry or other finder of fact. Each of these techniques has its own elements, and a discussion of expert witnessing is beyond the scope of this chapter. However, for our purposes, we will stipulate that the EEDI process emphasizes the use of timelines as an embodiment of the clarification element of this class. For more information on expert witness testimony, see Chapter 73 in this Handbook.

55.2 END-TO-END DIGITAL INVESTIGATION. The end-to-end digital inves- tigation process takes into account a structured process including the network involved, the attack computer, the victim computer, and all of the intermediate devices on the network. Structurally, it consists of nine steps:

1. Collecting evidence 2. Analysis of individual events

Bosworth, S., Kabay, M. E., & Whyne, E. (Eds.). (2014). Computer security handbook, set. Retrieved from http://ebookcentral.proquest.com Created from apus on 2018-03-19 16:25:53.

C o p yr

ig h t ©

2 0 1 4 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

55 · 10 CYBER INVESTIGATION

3. Preliminary correlation 4. Event normalizing 5. Event deconfliction 6. Second-level correlation (consider both normalized and nonnormalized events) 7. Timeline analysis 8. Chain of evidence construction 9. Corroboration (consider only nonnormalized events)

55.2.1 Collecting Evidence. A formal definition of the term evidence collec- tion is:

The use of approved tools and techniques by trained technicians to obtain digital evidence from computer devices, networks, and media. By approved we mean those tools and techniques generally accepted by the discipline and the courts where collected evidence will be presented.17

The collection of evidence in a computer security incident is time sensitive. When an event occurs (or when an expected event fails to occur), we have the first warning of a potential incident. An event may not be, by itself, particularly noteworthy. However, taken in the context of other events, it may become extremely important. From the forensic perspective, we want to consider all relevant events, whether they appear to have been tied to an incident or not. Events are the most granular elements of an incident.

We define an incident as a collection of events that lead to, or could lead to, a compromise of some sort. That compromise may include unauthorized change of control over data or systems; disclosure or modification of a system or its data; data or system destruction of the system; or unauthorized alterations in availability or utility or its data. An incident becomes a crime when a law or laws is/are violated.

Collecting evidence from all possible locations where it may reside must begin as soon as possible in the context of an incident. The methods vary according to the type of evidence (forensic, logs, indirect, traditionally developed, etc.). It is important to emphasize that EEDI is concerned not only with digital evidence. Gathering witness information should be accomplished as early in the evidence collection process as possible. Witness impressions and information play a crucial role in determining the steps the forensic examiner must take to uncover digital evidence.

Critical in this process are:

� Images of effected computers � Logs of intermediate devices, especially those on the Internet � Logs of effected computers � Logs and data from intrusion detection systems, firewalls, and so on

55.2.2 Analysis of Individual Events. An alert or incident is made up of one or more individual events. These events may be duplicates reported in different logs from different devices. These events and duplications have value both as they appear and after they are normalized. This analysis step examines isolated events and assesses what value they may have to the overall investigation and how they may tie into each other.

Bosworth, S., Kabay, M. E., & Whyne, E. (Eds.). (2014). Computer security handbook, set. Retrieved from http://ebookcentral.proquest.com Created from apus on 2018-03-19 16:25:53.

C o p yr

ig h t ©

2 0 1 4 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

END-TO-END DIGITAL INVESTIGATION 55 · 11

55.2.3 Preliminary Correlation. The formal definition of the term correla- tion is:

The comparison of evidentiary information from a variety of sources with the objective of discovering information that stands alone, in concert with other information, or corroborates or is corroborated by other evidentiary information.

Preliminary correlation examines the individual events to correlate them into a chain of evidence. The main purpose is to understand in broad terms what happened, what systems or devices were involved, and when the events occurred.

The term chain of evidence refers to the chain of events related in some consistent way that describes the incident. The relationship may be temporal or causal. Temporal chains are also called timelines. Essentially they say “This happened, then that hap- pened.” Causal relationships imply cause and effect. They say “That happened because this happened.”

The term chain of evidence must not be used as a synonym for chain of custody, which this chapter defines in the discussion of the Preservation class of the DFRWS framework.

55.2.4 Event Normalizing. The formal definition of normalization is:

The combining of evidentiary data of the same type from different sources with different vocabularies into a single, integrated terminology that can be used effectively in the correlation process.

Some events may be reported from multiple sources. During part of the analysis (timeline analysis, e.g.), these duplications must be eliminated. This process is known as normalizing. EEDI uses both normalized and nonnormalized events.

55.2.5 Event Deconfliction. The formal definition of deconfliction is:

The combining of multiple reportings of the same evidentiary event by the same or different reporting sources, into a single, reported, normalized evidentiary event.

Sometimes events are reported multiple times from the same source. An example is a denial-of-service attack where multiple packets are directed against a target and each one is reported individually by a reporting resource. The EEDI process should not count each of those packets as a separate event. The process of viewing the packets as a single event instead of multiple events is called deconfliction.

55.2.6 Second-Level Correlation. Second-level correlation is an extension of earlier correlation efforts. However, at this point, views of various events have been refined through normalization or deconfliction. For example, during the process of deconfliction or normalization, we have simplified the collection of events to elimi- nate redundancies and/or ambiguities. The resulting data set now represents the event universe at it simplest (or nearly simplest). These events (some of which actually may be compound events, i.e., events composed of multiple subevents) now represent the building blocks with which we may build chains of evidence.

Bosworth, S., Kabay, M. E., & Whyne, E. (Eds.). (2014). Computer security handbook, set. Retrieved from http://ebookcentral.proquest.com Created from apus on 2018-03-19 16:25:53.

C o p yr

ig h t ©

2 0 1 4 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

55 · 12 CYBER INVESTIGATION

55.2.7 Timeline Analysis. In this step, normalized and deconflicted events are used to build a timeline using an iterative process that should be updated constantly as the investigation continues to develop new evidence. The entire process is itera- tive: Event analysis, correlation, deconfliction, and timeline analysis are repeated in sequence as required.

55.2.8 Chain of Evidence Construction. Once there is a preliminary time- line of events, the process of developing a coherent chain of evidence begins. Ideally, each link in the chain, supported by one or more pieces of evidence, will lead to the next link. That rarely happens in large-scale network traces, however, because there often are gaps in the evidence-gathering process due to lack of logs or other missing event data.

Such problems do not invalidate this step, however. Although we may not always be able to construct a chain of evidence directly, we can nonetheless infer missing links in the chain. Now, an inferred link is not evidence: It is more properly referred to as a lead. Leads can point us to valid evidence and that valid evidence can, at some point, become the evidence link. Thus again, the iterative process of refinement of evidence makes it perfectly reasonable to start with a chain that is part evidence and part leads and refine it into an acceptable chain of evidence.

A second approach to handling gaps in evidence is to corroborate the questionable link very heavily. If all corroboration points to a valid link, it may be acceptable. For most purposes, however, the former approach is best.

55.2.9 Corroboration. In this stage, we attempt to corroborate each piece of evidence and each event in our chain with other, independent evidence or events. For this process, we use the noncorrelated event data as well as any other evidence developed either digitally or traditionally. The best evidence is that which has been developed digitally and corroborated through traditional investigation or vice versa. The final evidence chain consists of primary evidence corroborated by additional secondary evidence. This chain will consist of both digital and traditional evidence. The overall process does not differ materially between an investigation and an event postmortem except in use of the outcome.

55.3 APPLYING THE FRAMEWORK AND EEDI. The important issue in ap- plication is evidence management. Both the framework and EEDI help the investigator manage evidence. They do not substitute for good investigative techniques. The inci- dent may or may not be a criminal act; even if it is such an act, it may not be treated as one. No matter. The approach to investigating is essentially the same in either case. To understand how these investigative tools might apply, it is useful to begin with a generalized framework for understanding the execution of a cyber incident.

55.3.1 Supporting the EEDI Process. Experienced traditional investigators often resist a process-based approach to investigation. However, in numerous interviews with such investigators, the author determined that what these investigators do by habit and experience is almost exactly the same process discussed in this chapter. Thus, it is convenient to view the DFRWS framework and EEDI as tools that investigators can use to apply past physical investigation experience to the more complicated requirements of digital investigation.

Bosworth, S., Kabay, M. E., & Whyne, E. (Eds.). (2014). Computer security handbook, set. Retrieved from http://ebookcentral.proquest.com Created from apus on 2018-03-19 16:25:53.

C o p yr

ig h t ©

2 0 1 4 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

APPLYING THE FRAMEWORK AND EEDI 55 · 13

55.3.2 Investigative Narrative. The investigative narrative typically consists of the investigator’s notes. The EEDI process supports the construction of an investi- gation around an investigative framework. For the purposes of this chapter, we use the DFRWS framework shown in Exhibit 55.2. The framework includes the basic areas where investigative and forensic controls are required. Once the narrative is complete, it can be translated into a more structured evidence support and management process using the framework and EEDI.

For example, under the Collection class, we find reference to approved software, hardware, and methods. This indicates that the forensic software, hardware, and meth- ods used by the investigator or digital forensic examiner must meet some standard of acceptance within the investigative community. That standard usually refers to court testing. Should the investigator or forensic examiner not adhere to that standard, the evidence collected will be subject to challenge. At critical points in the investigation, such as the collection of primary evidence, such a lapse could jeopardize the outcome materially.

Again, the framework does not necessarily alter the generalized investigative tech- niques of experienced investigators and forensic examiners. Rather, it adds a dimension of rigor and quality assurance to the digital investigative process. It also ties the func- tions of the forensic examiner and the investigator tightly together, ensuring that the chain of evidence is properly supported, developed, and maintained.

55.3.3 Intrusion Process. Today, there are many ways in which an attack can occur. There has been a shift since about 2000 in types of incidents from manual hacking to automated malware-generated attacks. The sources of these attacks vary widely over time, and there is no definitive pattern to how they work. Today’s assaults typically are some form of blended attack. Examples are botnets, spam, Trojan horses, rootkits, worms, and other malware. (See Chapters 2, 13, 15, 16, 17, and 18 in this Handbook for more details of attack methods.)

A blended attack is one in which various intrusion techniques are combined to deliver a payload. The payload can be a malicious outcome, such as damaging the target computer, or it can be more subtle, such as a spybot that harvests personal information and calls home periodically to deliver its collected information.

Regardless of the intrusion technique—manual hacking or automated malware— there is a generalized pattern of activities associated with a cyber attack. These steps are:

� Information gathering. Information gathering usually does not touch the victim. During this phase, the attacker selects his or her target, researches it, and deter- mines such things as expected range of IP addresses exposed to the Internet. There is an exception to not touching the victim: Sometimes an attacker performs a scan of a block of IP addresses to determine whether there are any vulnerable devices in the IP block. This is what security professionals usually call a script-kiddie attack. The usual use for this step, however, is to select a victim for a targeted attack.

� Footprinting. Footprinting is the act of scanning a block of addresses owned by a victim for those that are online and may be vulnerable. The attacker is obtaining the footprint of the victim’s presence online.

� Enumerating. Enumerating refers to the analysis of exposed addresses for poten- tial weaknesses. In this step, the attack may grab banners to determine the versions

Bosworth, S., Kabay, M. E., & Whyne, E. (Eds.). (2014). Computer security handbook, set. Retrieved from http://ebookcentral.proquest.com Created from apus on 2018-03-19 16:25:53.

C o p yr

ig h t ©

2 0 1 4 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

55 · 14 CYBER INVESTIGATION

of various services running on the target. The objective is to understand what the victim is running on exposed machines. Once that information is gathered, the attacker can select potentially successful exploits based on published vulnerabili- ties. Although this process will leave a footprint on the target, it is likely to remain hidden in thousands of lines of logs (as in the footprinting phase). If these two steps (footprinting and enumerating) are performed carefully, they will not trigger most intrusion detection systems.

In a fully automated attack, such as one resulting from some form of social engineering (phishing, e.g.), these two steps are replaced by research that focuses on people and their access methods (e.g., email addresses). (For more information on social engineering, see Chapter 19 in this Handbook; for more on phishing, see Chapter 20.)

� Probing for weaknesses. In this step, the attacker may perform a vulnerability scan or some more stealthy probes to determine specific exploitable vulnerabili- ties. In an automated attack, this phase may consist of attempting to seduce large numbers of targets to give up important information that can be used in the next step. In this case, the probes consist of social engineering attempts.

� Penetration. This is the entry phase. It is essentially the same no matter if the attack is manual or automated. Only the penetration technique changes. The objective always is to reach into the victim system.

� Backdoors, Trojans, rootkits, and so on. In this phase, the attacker deposits the payload. The objective may be to reenter the target at some later date, plant some malware, or take the system down with a denial-of-service attack. Most experts seem to agree that denial-of-service attacks are on the decline. The objective of today’s intruders is more frequently stealing information than damaging systems. (For more about denial-of-service attacks, see Chapter 18 in this Handbook.)

� Cleanup. In a traditional hack, this step is where the attacker removes tools from the target, alters logs, and performs other actions to cover his or her tracks and obscure his or her presence from system administrators and forensic analysts. In an automated attack, the tasks are similar and have similar objectives, but the techniques are a bit different and the forensics required to find evidence are a bit different.

55.3.4 Describing Attacks. Three factors lead to a successful attack:

1. The attacker can access the target. 2. There is a significant vulnerability to attack, and that vulnerability can be identi-

fied by the attacker.

3. The attacker needs to have effective command and control and the prospects for attribution are minimized.

It is important to be able to describe a cyber event in clear terms. There are several attack taxonomies and descriptive languages available to help do that. However, these tools, while useful, are inconsistent with each other (there is no universally accepted descriptive language or taxonomy) and are often unnecessarily complicated for smaller investigations. The author recommends Howard’s common language18 as a good start- ing point for something simple and concise. Before applying a common language, however, there are several questions that need to be asked.

Bosworth, S., Kabay, M. E., & Whyne, E. (Eds.). (2014). Computer security handbook, set. Retrieved from http://ebookcentral.proquest.com Created from apus on 2018-03-19 16:25:53.

C o p yr

ig h t ©

2 0 1 4 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

APPLYING THE FRAMEWORK AND EEDI 55 · 15

� Description of the attack. This is a narrative describing how the attack appeared when analyzed: What is happening? What service is being targeted? Does the service have known vulnerabilities or exposures?

� Type of attack. Is it benign, an exploit, a denial-of-service attack or reconnais- sance?

� Attack mechanism. This is a narrative describing how the attack was carried out: How did the attacker do it?

� Correlations. How does this attack compare with other similar attacks? Are there any other attacks happening at the moment that might help trace/explain the attack?

� Evidence of active targeting. Is the attack leveled against one or more specific targets, or is it a generic blast?

� Severity. Severity = (Target Criticality + Attack Lethality) − (System Countermeasures

+ Network Countermeasures) Severity formula values usually are from 1 to 5, with 5 representing the highest

measure. These computations are for heuristic purposes only and do not purport to be rigorous metrics.

In answering these questions, the analyst may apply the common language (or other formal approach) as appropriate.

There are also 10 generalized questions about the incident that need to be resolved early in the investigation. These can form an informal template for early interviews.

1. What is the nature of the incident? 2. How can we be sure that there even was an incident? 3. What was the entry point into the target system? Was there only one? 4. What would evidence of an attack look like? What are we looking for? 5. What monitoring systems were in place that might have collected useful data

before and during the incident?

6. What legal issues need to be addressed (policies, privacy, subpoenas, warrants, etc.)?

7. Who was in a position to cause/allow the incident to occur? 8. What security measures were in place at the time of the incident? 9. What nontechnical (business) issues may have impacted the success or failure of

the attack?

10. Who knew what about the attack, and when did they know it?

55.3.5 Strategic Campaigns. The steps in an attack are, largely, tactical. This is what may be expected from an attacker during an individual attack. Often the tactical attacks are part of larger strategic campaigns. Examples are spam, identity theft carried out by organized groups, and politically motivated cyber war. There are three important differences between a tactical attack and a strategic campaign:

1. Single objective versus ongoing objectives 2. Low-hanging fruit versus sustained effort to penetrate 3. Trivial versus complicated targets and objectives

Bosworth, S., Kabay, M. E., & Whyne, E. (Eds.). (2014). Computer security handbook, set. Retrieved from http://ebookcentral.proquest.com Created from apus on 2018-03-19 16:25:53.

C o p yr

ig h t ©

2 0 1 4 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

55 · 16 CYBER INVESTIGATION

Attacks may be part of campaigns. However, just because a company experiences a tactical attack does not mean that it is part of a sustained campaign. Campaigns have distinct phases:

1. Mapping and battle space preparation 2. Offensive and defensive planning 3. Initial execution 4. Probes, skirmishes 5. Adjustment and sustainment 6. Success and termination

55.4 USING EEDI AND THE FRAMEWORK. Once we understand how at- tackers attack, we can see how EEDI and the framework can help us. The first, and most obvious, application of EEDI is the application of the investigative process to identify the results of each of the attack phases above. The act of collecting evidence, for example, may lead us to performing a forensic analysis of the target computer. When we do that, we will want to refer to the framework to ensure that we have not missed some important task. We may apply each step of the EEDI process to each step of the attack process to gather, correlate, and analyze evidence of an attack.

� Collecting evidence. Perform appropriate log collection, forensic imaging, and so on. Conduct interviews. There are 10 classes of evidence that the investigator should collect:

1. Logs from monitoring devices 2. Logs from hosts and servers 3. Firewall and router (especially edge router) logs 4. Interviews with involved personnel 5. Interviews with business and technical managers 6. Device configuration files 7. Network maps 8. Event observation timelines 9. Notes of relevant meetings 10. Response team notes and observations

� Analysis of individual events. Consider each of the events revealed by the col- lection and analysis of evidence in step one. Look for evidence of enumeration, penetration, and cleanup.

� Preliminary correlation. Tie together events from logs so that a smaller evidence set emerges. Consider each step of the attack process that applies to the device or system under analysis. Generate a straw-man chain of evidence.

� Event normalizing. The first and most important aspect of normalizing is time stamping. It is unlikely that all of the involved devices are on the same time tick. In this step, some allowance for differences in time zones and clocks must be made. Other normalizing tasks include combining different reports of the same events.

� Event deconfliction. This simply is an extension of event normalizing.

Bosworth, S., Kabay, M. E., & Whyne, E. (Eds.). (2014). Computer security handbook, set. Retrieved from http://ebookcentral.proquest.com Created from apus on 2018-03-19 16:25:53.

C o p yr

ig h t ©

2 0 1 4 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

MOTIVE, MEANS, AND OPPORTUNITY: PROFILING ATTACKERS 55 · 17

� Second-level correlation. This is a further refinement of the evidence and the straw-man chain of evidence. Here an important task is correlating log events, media forensic results, and results of interviews into a clear chain of evidence. This chain should be both causal and temporal, although the emphasis on the temporal chain is in the next step. This step is distinguished from the next two steps by level of detail. This correlation should offer significant detail. The next steps refine that detail making the results more comprehensible to laypeople.

� Timeline analysis. Refine the level of detail in the temporal chain of evidence. � Chain of evidence construction. Refine the level of detail in the causal chain of evidence.

� Corroboration. Apply as much corroboration to evidence associated with each step of the attack process as you can.

55.5 MOTIVE, MEANS, AND OPPORTUNITY: PROFILING ATTACKERS. Attacks, even automated ones, are performed by people. In order to understand attacks, we must understand the people who deliver them. We call those people threat agents because an attack simply is the delivery of a threat against a target. The act of delivering a threat is described concisely by Jones.19 His model appears in Exhibit 55.3.

According to Jones, the threat agent first must have the capability of delivering the threat: The attacker must have access to the threat and know what to do with it. An example is an attacker who delivers a virus to a target system. The virus is the threat, and the attacker is the threat agent.

The threat agent then must be motivated to carry out the attack. However, just because motivation exists does not mean that a wily attacker will deliver the threat immediately. Usually, there needs to be a catalyst which tells the attacker that, for whatever reason, the time has come to attack.

The next step in the process, access, is the first place that we can manage the attack. Denying the threat agent access to the target denies the threat agent the ability to deliver the threat. However, assuming that the attacker can obtain access, the effectiveness of

Threat Agent

Catalysts

Access

Amplifiers

THREAT

Inhibitors

Motivation

Capability

EXHIBIT 55.3 Jones’s Threat Delivery Model

Bosworth, S., Kabay, M. E., & Whyne, E. (Eds.). (2014). Computer security handbook, set. Retrieved from http://ebookcentral.proquest.com Created from apus on 2018-03-19 16:25:53.

C o p yr

ig h t ©

2 0 1 4 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

55 · 18 CYBER INVESTIGATION

Threat Agent

Catalysts

AccessOpportunity

Amplifiers

THREAT

Inhibitors

Motivation

Capability Means

Motive

EXHIBIT 55.4 Jones’s Model Showing Motive, Means, and Opportunity

the attack is now determined by the amplifiers and inhibitors present in the target system. These steps have direct analogs in the notion of motive, means, and opportunity, as Exhibit 55.4 shows.

55.5.1 Motive. Motive is critically important to understanding an attack. Why an attacker attacks often helps us understand the attack and, ultimately perhaps, who the attacker is. Traditional profiling matches evidence to known perpetrator profiles to understand the perpetrator. We do the same thing in cyber investigation.

An attacker with the motive of stealing personally identifiable information for the purpose of identity theft or credit card fraud may have an entirely different motive from a disgruntled employee who performs the same act to get even with his or her employer. In the former case, the attacker is motivated strictly by financial gain. In the latter, the attacker is motivated by a need for revenge.

Understanding the motivation helps us to determine the level of threat. In the former case, since the motivation is financial, the threat is significant and potentially far reaching because the attacker could attempt to maximize financial return. In the latter case, the threat could be somewhat less because, having stolen the information, the attacker might be likely to publicize his or her act in order to get the revenge desired. This might result in extortion attempts or leaks to the media but not in the attempt to sell or profit from the theft through sale of the information.

Additionally, analysis of motivation can help determine if the attacker is likely to be an individual or is part of a group. Groups tend to have somewhat different motivations from individuals, and they manage their attacks differently. There are several classes of threat agents, and each one has its own unique motive set. A summary appears in Exhibit 55.5.

The FBI, prior to 1995, described motive in general terms in its adversarial matrix.20

Although this matrix needs updating for current trends and technology, it still is amaz- ingly accurate and provides useful guidelines to the investigator. The behavioral char- acteristics appear in Exhibit 55.6, which is drawn from a British source.21 This equates, approximately, to motive.

Bosworth, S., Kabay, M. E., & Whyne, E. (Eds.). (2014). Computer security handbook, set. Retrieved from http://ebookcentral.proquest.com Created from apus on 2018-03-19 16:25:53.

C o p yr

ig h t ©

2 0 1 4 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

MOTIVE, MEANS, AND OPPORTUNITY: PROFILING ATTACKERS 55 · 19

States

Theft of intellectual property

Disruption Organized crime and terrorists

Money laundering Theft of trade secrets for

resale Disruption Competitors

Competitive advantage

Cyber mercenaries

Personal gain Gangs, new-age gangs

Financial gain Lone hackers and hacker “clubs”

Peer respect and power Occasionally knowledge

Disgruntled employee Revenge Personal gain

EXHIBIT 55.5 Types of Threat Agents and Their Motivations

EXHIBIT 55.6 Adversarial Matrix Behavioral Characteristics

Category of Offenders Motivation

Personal Characteristics

Potential Weaknesses

Crackers Groups Intellectual challenge;

peer group fun; in support of a cause

Highly intelligent individuals, counterculture orientation

Do not consider offenses crimes, talk freely about actions

Individuals Intellectual challenge; problem solving; power; money; in support of a cause

Moderately to highly intelligent

May keep notes and other documents of actions

Criminals Espionage Money and a chance

to attack the system May be crackers

operating in groups or as individuals

Become greedy for more information and then become careless

Fraud/Abuse Money or other personal gain; power

Same personal characteristics as other fraud offenders

Become greedy and make mistakes

Vandals Strangers Intellectual challenge;

power; money Same characteristics

as crackers May become too brazen and make mistakes

Users Revenge against organization; problem solving; money

Usually have some computer expertise

May leave audit trail in computer logs

Bosworth, S., Kabay, M. E., & Whyne, E. (Eds.). (2014). Computer security handbook, set. Retrieved from http://ebookcentral.proquest.com Created from apus on 2018-03-19 16:25:53.

C o p yr

ig h t ©

2 0 1 4 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

55 · 20 CYBER INVESTIGATION

Jones also describes a motivation taxonomy:

� Political � Secular � Crime � Personal gain � Revenge � Financial � Knowledge or information � Peer recognition � Power � Curiosity � Religion � Terrorism � Competitive advantage � Belief

55.5.2 Means. Means is a very important part of the profile. In cyber investiga- tion, we generally equate means directly to the tools and techniques used in the attack. Indirectly we relate means to skill level of the attacker. We live in an Internet-enabled society. That state of affairs extends to computer-related crime. Relatively unskilled threat agents can deliver moderately sophisticated attacks simply because the means is readily available on the Internet to enable their actions. Analysis of evidence for indications of skill level helps us to eliminate suspects.

A word on investigative process is in order here. Although it may seem as if the right approach to an investigation is to focus on the probable perpetrator, in reality, it is far more productive, initially at least, to focus on those who absolutely could not be the perpetrator. This is an extension of the Sherlock Holmes’ admonition: “It is an old maxim of mine that when you have excluded the impossible, whatever remains, however improbable, must be the truth.”22 The point here is that it is far more efficient to eliminate those who could not have participated in the attack. In cyber investigations, doing this becomes even more important because of the huge universe of possible participants in a network-based attack.

The FBI adversarial matrix of operational characteristics appears in Exhibit 55.7. Exhibit 55.8 extends the operational characteristics and includes specific tools, tech- niques, and support required. These equate, approximately, to means.

55.5.3 Opportunity. The Jones threat model describes the notion of opportu- nity. Considered with means, opportunity helps determine whether an attacker is a credible threat agent. Opportunity not only reflects Jones’ threat model, it includes such things as knowledge of the victim system. The insider threat is an important piece of the opportunity puzzle. In this case, an insider can be the attacker him- or herself or a confederate of the threat agent. Besides insider help, the attacker may have the support of a group of some sort, such as a hacker gang, drug gang, or organized crime group.

Bosworth, S., Kabay, M. E., & Whyne, E. (Eds.). (2014). Computer security handbook, set. Retrieved from http://ebookcentral.proquest.com Created from apus on 2018-03-19 16:25:53.

C o p yr

ig h t ©

2 0 1 4 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

SOME USEFUL TOOLS 55 · 21

EXHIBIT 55.7 FBI Adversarial Matrix of Operational Characteristics

Category of Offenders Planning

Level of Expertise

Tactics/Method Used

Crackers Groups May involve

detailed planning High Each target computers

via computer networks, exchange information with other crackers and groups

Individuals Study networks before attempts are made

Medium to high, Experience gained through social networks

Use networks but more likely to use trial and error online than to do careful research and planning, use BBSs share accounts on other systems

Criminals Espionage Same

characteristics as crackers

High May contract with crackers to conduct information and data collection

Fraud/Abuse Careful planning prior to crime

Medium to high, although is typically more experienced at fraud than at computer programming

May use more traditional intrusion methods, such as wiretapping and trapdoors, will break into systems using basic methods

Vandals Strangers Not much planning,

more a crime of opportunity

Varies Looks around until able to gain access to system

Users May involve detailed planning and execution

Varies, may have high level of expertise

Trapdoors and Trojan horse programs, data modification

55.6 SOME USEFUL TOOLS. The usual tools for digital investigation include tools for:

� Computer forensic imaging and analysis � Network forensic/log aggregation and analysis � Malware discovery � Media imaging (without analysis) � Network discovery � Remote (over-the-network) computer forensic analysis and imaging

These tools are well known in the cyber forensic community and do not warrant further elucidation here.23 Specific products come and go so it is not appropriate to provide that level of detail here.

Bosworth, S., Kabay, M. E., & Whyne, E. (Eds.). (2014). Computer security handbook, set. Retrieved from http://ebookcentral.proquest.com Created from apus on 2018-03-19 16:25:53.

C o p yr

ig h t ©

2 0 1 4 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

55 · 22 CYBER INVESTIGATION

EXHIBIT 55.8 FBI Adversarial Matrix Resource Characteristics

Category of Offenders Training Skills

Minimum Equipment Needed

Support Structure

Crackers Groups High level of informal

training Basic computer equipment with modem

Peer group support

Individuals Expertise gained through experience

Basic computer equipment with modem

BBS, information exchanges

Criminals Espionage Various level of

expertise Basic computer equipment with modem, in some cases, uses more sophisticated devices

Support may come from sponsoring intelligence agency

Fraud/Abuse Some programming experience

Computer with modem or access to target computer

Peer group support, possible organized crime enterprise

Vandals Strangers Range from basis to

highly skilled Basic computer equipment with modem

Peer group support

Users Some computer expertise, knowledge of programming ranges from basic to advanced

Access to targeted computer

None

In addition, there are some nonstandard tools that can make the EEDI process much easier. These include:

� Link analysis � Attack-tree analysis � Modeling � Statistical analysis

Unlike the standard tools, these specialized requirements bear explanation. Again, however, specific products come and go. Where examples are provided, the specific product that generated the example will be listed along with its source at the time of writing.

55.6.1 Link Analysis. In this author’s view, link analysis is the single most useful technique for cyber investigators. Link analysis allows the investigator to analyze large data sets for nonobvious relationships. Link analysis is used in the investigation of complicated criminal activities, such as fraud, drug-related activities and groups,

Bosworth, S., Kabay, M. E., & Whyne, E. (Eds.). (2014). Computer security handbook, set. Retrieved from http://ebookcentral.proquest.com Created from apus on 2018-03-19 16:25:53.

C o p yr

ig h t ©

2 0 1 4 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

SOME USEFUL TOOLS 55 · 23

terrorist acts and groups, and organized crime. It is used far less commonly in analysis of cyber crime, but it should be integrated into cyber investigations.

The core theory behind link analysis is that pairings of related items (e.g., people and addresses, source and destination IP addresses, hacker aliases and real names, etc.) can be analyzed to find relationships that are not immediately obvious. We do that by testing for associations in suitable pairs of data sets.

An example of such an analysis is an analysis of hackers and groups. We might start by pairing hacker aliases and real names. These can be collected in a simple spreadsheet in columns with the first column as hacker aliases. Through research, the real names of some of the hackers may be discovered and be placed into their own column next to their associated aliases. Next, research may reveal hacks associated with individual aliases or, perhaps, real names. These go into their own column in the same row with their associated hackers. Finally, perhaps the groups with which the hackers are associated can provide useful connections. These groups are researched and placed in their own column on the rows associated with the hackers who are members.

The link analyzer accepts the input two columns at a time and iteratively analyzes the relationships. Some of the things that the analysis might reveal are multiple aliases for the same hacker, multiple hackers participating in the researched hacks, and mem- bership in various hacker groups. In turn, membership in a particular hacker group may imply participation in individual hacks by members of the group who were not initially reported as being involved.

A more difficult problem to solve is the relationship between attack source IP addresses and target addresses. Often these relationships are clustered. In link analysis language, a cluster is

a group of entities that are bound more tightly to one another by the links between them than they are to the entities that surround them.24

Since the entities within a cluster are more tightly interconnected within the cluster than they are with entities outside of the cluster, these clustered entities usually represent activities of interest.

Applying this concept to a large log from a firewall, we might take all of the denied connections, place their source and destination addresses in the link analyzer, and look for relationships. That might yield a complicated pattern such as the one shown in Exhibit 55.9.

This map can be simplified by performing a cluster analysis as shown in Ex- hibit 55.10.

The clustering operation on the data in Exhibit 55.9 reveals the cluster in Exhibit 55.10. This simplified analysis in turn shows two interesting relationships:

1. It quickly identifies the IP addresses that are broadcasting. 2. It clearly shows several IP addresses that are receiving a lot of traffic as well as

the sources of that traffic.

The cluster map in Exhibit 55.10 is far easier to read than the map in Exhibit 55.9. Considering that the original log had several thousand entries, this is a much improved way to see nonobvious relationships; it is much easier than reading the log data or manipulating a spreadsheet.

Bosworth, S., Kabay, M. E., & Whyne, E. (Eds.). (2014). Computer security handbook, set. Retrieved from http://ebookcentral.proquest.com Created from apus on 2018-03-19 16:25:53.

C o p yr

ig h t ©

2 0 1 4 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

55 · 24 CYBER INVESTIGATION

EXHIBIT 55.9 Link Analyzer Relationship Map of Source and Destination IP Addresses

55.6.2 Attack-Tree Analysis. Attack-treeanalysis is a technique for analyzing possible attack scenarios on a compromised network. Its purpose is to hypothesize the attack methodology and calculate the probabilities of several possible scenarios. Once these probabilities are calculated, the investigator can hypothesize where to look for evidence. In a complicated attack on a large distributed network, having a set of these models on hand can be a big help. The analyst prepares various attack-tree models in advance and then modifies them to be consistent with the facts of a particular incident. This limits the number of high-probability attack paths and simplifies the evidence discovery process.

55.6.3 Modeling. Attack modeling is a broad term that refers to all of the techniques used to simulate attack behavior. The author uses Coloured Petri Nets (CPNets).25 CPNets are a graphical representation of a mathematical formalism that allows the modeling and simulation of attack behavior on a network. To use CPNets ef- fectively, the investigator must understand the enterprise in terms of its security-policy domains. The author defines security-policy domains in this way: “A security policy domain, Ep, consists of all of the elements, e, of an enterprise that conform to the same security policy, p.”26

The policy domains are represented along with the communications links between them in a graphical chart. Once the mathematical definitions of the domains and the

Bosworth, S., Kabay, M. E., & Whyne, E. (Eds.). (2014). Computer security handbook, set. Retrieved from http://ebookcentral.proquest.com Created from apus on 2018-03-19 16:25:53.

C o p yr

ig h t ©

2 0 1 4 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

FURTHER READING 55 · 25

Broadcast

192.168.6.58 747

1

3 192.168.6.78 90

1203

16787

6

192.168.3.3

192.168.6.76

192.168.6.66 7.4

28

167 3

3

3

3

192.168.6.596

192.168.6.25514

5

11

10

4

2

2

2

22

1

311

16

63

6

192.168.6.64

192.168.6.85

192.168.6.82

192.168.3.6

255.255.255.255

192.168.6.71

192.168.6.81 192.168.6.79

224.0.022

192.168.6.70

192.168.6.61

66

2 72

2 2

2

2 2

36 192.168.3.59383

2420

209.85.137.19 12

EXHIBIT 55.10 Map in Exhibit 55.9 Reduced through Cluster Analysis

communications conditions that exist between them have been defined, the behavior of the attack can be simulated. The simulations assist the investigator in tracing the attack source.

55.7 CONCLUDING REMARKS. In this chapter, we discussed a structured ap- proach to cyber investigation along with some of the tools and techniques that support such an approach. Nordby27 suggests that reliable methods of inquiry possess the characteristics of “integrity, competence, defensible technique and relevant experi- ence.” The nature of cyber investigation and cyber forensics supports this through rigor, underlying models and frameworks, and investigators who adhere to those characteristics.

55.8 FURTHER READING Brown, C. L. T. Computer Evidence: Collection & Preservation. Hingham, MA:

Charles River Media, 2005. Carrier. B. File System Forensic Analysis. Upper Saddle River, NJ: Addison-Wesley,

2005. Carvey, H. Windows Forensics and Incident Recovery. Upper Saddle River, NJ:

Addison-Wesley, 2004. Farmer, D., and W. Venema. Forensic Discovery. Upper Saddle River, NJ: Addison-

Wesley, 2005. Jones, K. J., R. Beijtlich, and C. W. Rose. Real Digital Forensics: Computer Security

and Incident Response. Upper Saddle River, NJ: Addison-Wesley, 2005.

Bosworth, S., Kabay, M. E., & Whyne, E. (Eds.). (2014). Computer security handbook, set. Retrieved from http://ebookcentral.proquest.com Created from apus on 2018-03-19 16:25:53.

C o p yr

ig h t ©

2 0 1 4 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

55 · 26 CYBER INVESTIGATION

Marcella, A., and D. Menendez. Cyber Forensics: A Field Manual for Collecting, Examining, and Preserving Evidence of Computer Crimes, 2nd ed. Boca Raton, FL: Auerbach, 2007.

Steel, C. Windows Forensics: The Field Guide for Corporate Computer Investigations. Hoboken, NJ: John Wiley & Sons, 2006.

55.9 NOTES 1. Much of this chapter is excerpted with minor edits from P. Stephenson, “Structured

Investigation of Digital Incidents in Complex Computing Environments,” PhD diss., Oxford Brookes University, 2004, available in the British Library.

2. P. Stephenson and K.Gilbert, Investigating Computer Related Crime (CRC Press, 1999).

3. American Academy of Forensic Science, 2008: http://www.aafs.org/membership 4. M. Rogers, A. Brinson, and A. Robinson, “A Cyber Forensics Ontology: Creating

a New Approach to Studying Cyber Forensics,” Journal of Digital Investigation (2006): S37–S43.

5. Microsoft R© Encarta R© 2008, “Metaphysics” [DVD] (Microsoft Corporation, 2008). 6. Microsoft R© Encarta R© 2008 Dictionary [DVD] (Microsoft Corporation, 2008). 7. Open-source ontology editor available from http://protege.stanford.edu/ 8. Digital Forensic Research Workshop: http://dfrws.org/ 9. DFRWS attendees, “A Road Map for Digital Forensic Research,” Report from

the First Digital Forensic Research Workshop, August 7–8, 2001, Utica, NY. Air Force Research Laboratory, Rome Research Site, Rome, NY, http://dfrws.org/ 2001/dfrws-rm-final.pdf

10. There have also been attempts to relate cyber investigation to the generalized Zachman Enterprise Architecture Framework: J. A. Zachman, “A Framework for Information Systems Architecture,” IBM Systems Journal 26, No. 3 (1987), http://www.zachmanframework.com/images/ZI PIcs/ibmsj2603e.pdf

11. DFRWS attendees, “A Road Map for Digital Forensic Research.” 12. DFRWS attendees, “A Road Map for Digital Forensic Research.” 13. The DFRWS definitions in these sections are from Digital Forensics Research

Workshop, “Day 1-DF-Science, Group A Session 1 (D1-A1), Digital Forensic Framework,” Work notes for the 2003 Digital Forensics Research Workshop, Au- gust 6, 2003. For more information on the DFRWS Framework, see DFRWS attendees, “Road Map for Digital Forensic Research.”

14. Author’s experience over 25 years of conducting incident response. 15. A. C. Doyle, “Silver Blaze.” In: The Memoirs of Sherlock Holmes (Newnes, 1893).

http://www.gutenberg.org/files/834/834-h/834-h.htm 16. A gross data collection is a file or files containing data collected from a digital

source that may contain individual evidentiary data. 17. This and other formal definitions appear in Stephenson, “Structured Investigation

of Digital Incidents in Complex Computing Environments.” 18. See Chapter 8, Sections 8.1 to 8.6, in this Handbook. 19. Andrew Jones describes a cyber threat delivery model in his paper “Identification

of a Method for the Calculation of Threat in an Information Environment,” unpublished (April 2002, revised 2004). http://www.researchgate.net/publication/

Bosworth, S., Kabay, M. E., & Whyne, E. (Eds.). (2014). Computer security handbook, set. Retrieved from http://ebookcentral.proquest.com Created from apus on 2018-03-19 16:25:53.

C o p yr

ig h t ©

2 0 1 4 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

NOTES 55 · 27

228957980 Identification of a method for the calculation of threat in an inform ation environment

20. D. Icove, K. Seger, and W. VonStorch, Computer Crime: A Crimefighter’s Hand- book (O’Reilly & Associates, 1995.

21. Stephenson, “Structured Investigation of Digital Incidents in Complex Computing Environments.”

22. A. C. Doyle, The Sign of Four (Blackett, 1890). http://www.gutenberg.org/ ebooks/2097

23. For more details, see the recommendations for further reading. 24. i2 Limited “About Clusters,” Analyst’s Notebook v6 Help file, August 9, 2005;

http://www-03.ibm.com/software/products/us/en/analysts-notebook/ 25. Coloured Petri Nets at the University of Aarhus: http://www.daimi.au.dk/CPnets 26. P. Stephenson and P. Prueitt, “Towards a Theory of Cyber Attack Mechanics,”

First IFIP 11.9 Digital Forensics Conference, 2005. http://www.ontologystream .com/gFT/Towards a Theory of Cyber Attack Mechanics.PDF

27. S. H. James and J. J. Nordby, Forensic Science: An Introduction to Scientific and Investigative Techniques (CRC Press, 2003).

Bosworth, S., Kabay, M. E., & Whyne, E. (Eds.). (2014). Computer security handbook, set. Retrieved from http://ebookcentral.proquest.com Created from apus on 2018-03-19 16:25:53.

C o p yr

ig h t ©

2 0 1 4 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

Bosworth, S., Kabay, M. E., & Whyne, E. (Eds.). (2014). Computer security handbook, set. Retrieved from http://ebookcentral.proquest.com Created from apus on 2018-03-19 16:25:53.

C o p yr

ig h t ©

2 0 1 4 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .