Mike Wills - The Official (ISC)2 SSCP CBK Reference

Taken together, this means that the data your accounting functions generate must be reliable and verifiable as to its accuracy and completeness. Data that cannot unambiguously identify the subject or subjects in question and precisely identify the actions they took or attempted to take are of little value to the troubleshooter or the litigator.

You must also take actions to protect the accounting data and related information in various systems or applications log files from inadvertent or deliberate damage, alteration, or loss. This not only protects the chain of custody of such data as forensics evidence but also provides another opportunity for early detection of an intrusion or unauthorized access or usage attempt. For example, by routing all security-related event notifications and supporting data to a separate logging agent, which is protected by separate and distinct administrator credentials, you both protect the log data while providing another source of alarms if some other process (a subject), even one with systems administrator, root, or other elevated privileges, attempts to access that data. It's also good to keep in mind that unplanned system restarts can sometimes be part of attempts to obscure an attacker's actions, including their attempts to cover their tracks by altering log files.

It is worthwhile to consider all of your security-related information as high-value, high-payoff assets—ones where the losses to the organization if they are compromised, destroyed, or lost is far greater than the modest investments to properly gather, isolate, and protect this data. Don't let your log files overwrite themselves too quickly. Instead, work with your security experts and your legal team to set an effective data retention policy for this data and then implement this in your security information management practices and procedures.

Having said all of that, it's worth remembering that each month seems to bring news of even more sophisticated attack mechanisms being used by the black hats; in many cases, rootkits and other stratagems can alter the reality of your systems while keeping your perceptions of them largely intact. When all else fails, having “golden image” backup copies from which you can reinstall everything , from the bare metal up, may be your only safe and sane path back to normal, trustworthy operations.

Single sign-on (SSO) was the first outgrowth of needing to allow one user identity with one set of authenticated credentials to access multiple, disparate systems to meet organizational needs. SSO is almost taken for granted in the IT world—cloud-based service providers that do not support an SSO capability often find that they are missing a competitive advantage without it. On one hand, critics observe that if the authentication servers are not working properly (or aren't available), then the SSO request fails, and the user can do nothing. This may prompt some organizations to ensure that each major business platform they depend on has its own sign-on capability, supported by a copy of the central authentication server and its repository. SSO implementations also require the SSO server to internally store the authenticated credentials and reformat or repackage them to meet the differing needs of each platform or application as required. Because of this, SSO is sometimes called reduced sign-on .

SSO is an implementation of the federated identity concept, which focuses around four basic services: authentication, authorization, user attribute exchange, and user management. Authentication and authorization are the same familiar faces access control concepts. User attribute exchange provides a mapping of an authenticated and authorized user's identity into attributes or parameters that meet the unique needs of the different platforms, servers, and applications in your systems. This aspect of a federated identity management system also helps reduce redundancy by keeping one central edition of user data (such as their first and last names).

Multiple implementations of SSO are possible, using a variety of protocols and supporting software, including:

Kerberos-based ticket granting ticket (TGT) systems

Active Directory (which must be hosted on at least one system running Microsoft Windows Server)

Smart card based

Integrated Windows Authentication

SAML-based systems

A variety of protocols support SSO, such as Open ID Connect, Facebook Connect, SAML, and the Microsoft Account (which used to be known as Passport). A variety of frameworks can make implementing SSO for your organization less painful.

Remember, devices are subjects in access control terms; therefore, whenever a device attempts to establish a connection with your networks or with a system, your organization's information security requirements should dictate how rigorously that device must authenticate its identity and then how your systems will authorize it to take whatever actions (such as accesses to objects) it attempts to do.

Device identity should be established with a combination of hardware, firmware, and software characteristics; this allows your systems to confirm that not only is the device itself known to your authentication system, but its firmware, systems-level software, and applications are all at or above the required update or patch level. Other information, such as the human user or organizational identity associated with that device, might also be something that authentication and authorization functions check and verify. Be aware that all of this information, starting with hardware-level IDs such as the media access control (MAC) address, can be spoofed or altered; choose your mix of authentication factors for devices with this in mind.

Chapter 6will look into controlling and monitoring device access to your systems in greater depth, while Chapter 7will provide insights on improving data security. Both are necessary parts of your defense against a business-killing data exfiltration before it occurs.

There are days when it seems that our modern e-commerce world cannot live without a thumb drive or other USB storage device—yet with thumb drive storage capacities now coming in terabyte-sized chunks, the prospects of massive data exfiltration should be just as scary as the threat of removable media as a vector for introducing malware to your systems.

Think carefully as to whether the convenience of letting users connect any USB storage device they want to any aspect of your systems infrastructure is worth the risk.

Federated identity management systems provide mechanisms for sharing identity and access information, which makes identity and access portable, allowing properly authorized subjects to access otherwise separate and distinct security domains. Federated access uses open standards, such as the OASIS Security Assertion Markup Language (SAML), and technologies such as OAuth, OpenID, various security token approaches, web service specifications, Windows Identity Foundation, and others. Federated access systems typically use web-based SSO for user access (which is not to be confused with SSO within an organization's systems). Just as individual platform or system access is logically a subset of SSO, SSO is a subset of federated access. SSO, properly implemented, eases the administrative burden for systems administrators, makes end users' lives simpler, and significantly enhances systems security (and its auditability).

One outgrowth of federated identity and access management (IAM) approaches has been to emphasize the need for better, more reliable ways for entities to be able to assert their identity as a part of an e-business transaction or operation. Work to develop an identity assurance framework is ongoing, and there are efforts in the United States, United Kingdom, and a few other nations to develop standards and reference models to support this.