Biometric Technology – Part I

As technological advancements are increasingly immersed in routine human endeavors, few security professionals doubt the criticality for parallel and proportional achievements in information asset protection mechanisms to defend against threats from individuals or groups chasing infamy dreams. Contextually, those engaged in nefarious IT activities vigorously pursue stardom elevation by orchestrating information security attacks that render barriers to obtaining or affecting a targeted object impotent. When an information asset is deemed valuable, authorization through a single access scheme appears woefully inadequate compared to the estimated number of ‘hackers’ or ‘crackers’ probing IT operational defenses. Predictively, considering published organizational information security incidents, two or more authentication factors will inevitably become the security deployment norm, with one architectural authentication factor relying on a biometrically based process; unless superior alternative access control remedies are devised.

Trans-border Communication Protection – Part IV

The primary distinguishing feature between IPSec and SSL is their respective OSI reference model protocol communication tier levels. IPSec operates at the network layer of the OSI reference model while SSL operates at the transport layer. Protection mechanism utilization should be determined by information sensitivity. IPSec or SSL can be combined with a VPN to limit data interception, manipulation, and redirection. Standards exist for encryption systems, such as SSL and IPSec, which ensure compatibility among various hardware and software platforms. Comparatively, regarding trans-border privacy issues, SSL VPN can be considered a viable alternative to stand-alone IPSec deployment.

“View Part I of the Trans-border Communication Protection series here“

Trans-border Communication Protection – Part III

Generally, a VPN is recognized as a confidential data plexus that employs the public telecommunication infrastructure while maintaining privacy through the utilization of a tunneling protocol and security procedures. A VPN can provide remote offices and telecommuters with secure access to the connected local or wide area networks. When a VPN is introduced to the secure protocol privacy protection equation, IPSec and SSL technologies require mobile users to deploy client software on specific computers for utilization enablement.

Concerning secure access, virtual private networking requires a carrier as well as encapsulating protocol to provide tunneling functionality. Therefore, encryption, authentication, and data packaging usually are incorporated in a SSL VPN. Furthermore, below the OSI transport layer, a VPN can provide additional privacy data protection. This has many manifestations, the most popular being IPSec, typically implemented as a protected ‘tunnel’ between two gateway routers. An IPSec ‘vanilla’ VPN only uses the Encapsulating Security Payload (ESP) header record. However, ESP protects against IT communication eavesdropping, forgery, or replay risks.

“View Part I of the Trans-border Communication Protection series here“

Trans-border Communication Protection – Part II

SSL is a protocol suite enabling in transit security through data encryption, server authentication, and message integrity at four Open Systems Interconnection (OSI) reference model layers. For Internet communications, SSL is normally utilized in conjunction with an entity’s public key infrastructure. Commonly, when the trans-border privacy breach risk is low, the Hyper Text Transfer Protocol Security service is employed with SSL encryption to protect sensitive web packets. Beneficially, where SSL is integrated for required privacy related communication, applications no longer need to implement secure connectivity. Nevertheless, security managers should not interpret SSL deployment as the ‘bullet-proof’ technology that completely defers application communication privacy issues. Specifically, SSL should initiate deployment caution when utilized for mutual application authentication, since there are two different session keys seeking connectivity authorization during bidirectional interfaces. Consequently, each key should be verified before transmitting legally protected data.

Alternatively, IPSec is a protocol suite that enables security at five OSI reference model layers during internetworking communications. The IPSec model is an architecture composed of standard rules for protecting Internet Protocol traffic. These standard rules can be incorporated into transport and tunnel mode encapsulation. Tunnel mode provides two additional header records for sending messages, thus requiring more processing. Neither the application nor the stacking protocol needs to be cryptographically aware, since all designated traffic is encrypted regardless of origin within the entity’s information security perimeter. Possible IPSec issues are network device computational and/or bandwidth overhead.

“View Part I of the Trans-border Communication Protection series here“

Trans-border Communication Protection – Part I

Legal compliance with local, national and regional privacy requirements is complex and dynamic. Every problem on the local level compounds exponentially when private data is shared across multiple jurisdictions. What data is private, who possess particular data and what laws and regulations apply are by no means transparent. Trans-border communication privacy risks may emanate from sources presumed technologically secure, including the entity’s network architecture and/or application programs. Realization of how vulnerable data is in transit has spurred various, yet unique, technological communication protection solutions. The Internet Protocol Security (IPSec) and Secure Socket Layer (SSL) protocols are two well-known configuration items redressing privacy compliance mandates during information conveyance. However, in-depth security considerations can necessitate transporting messages within a Virtual Private Network (VPN).

Application Protection – Part IV

The FCPA impacts IT control requirements of U.S. publicly held enterprises. Section 78m (b), in particular, documents the legislative rules and compliance requirements of internal control evaluation reporting with regard to management’s assessment of internal controls. Section 78m (b) (2) through (5) applies to Securities Exchange Act of 1934 filers. Therefore, the FCPA can affect an organization’s internal control environment by indirectly imposing management’s assurance of an adequate IT control environment with adequate information protection. Based on the Public Company Accounting Oversight Board’s interpretation, the SOX IT control parameter, in effect, is the same as that of the FCPA. Therefore, U.S. Securities Exchange Act of 1934 filers may not be aware of FCPA legal requirements — yet, they should have been performing the necessary FCPA control self-assessments and remedial actions since 1977. Similarly, European Union, OAS, and OECD member countries should be engaging in control self-assessments and remediation of internal accounting controls as they relate to safeguarding information assets to ensure compliance with legal mandates.

“View Part I of the Application Protection series here”

Application Protection – Part III

FCPA control measures for an adequate system of internal accounting controls include maintaining appropriate segregation of duties, allowing only authorized transaction execution, controlling access to assets, and reconciling documented assets to actual assets regularly. Completeness, accuracy, authorization, and accessibility are considered key internal accounting information protection controls that fulfill FCPA legal requirements. These control measures most often interact with — or are deployed through — IT financial applications, thus justifying information security management’s involvement in assessing compliance with the FCPA.

To dispatch FCPA information reliability requirements, an information security manager should identify, understand, test, and document internal accounting security controls for information assets. Essentially, an information security manager should assume responsibility for assessing financial applications for FCPA safeguarding compliance. Technically, application safeguarding controls should be present during input, processing, and output. IT procedures are expected to provide information protection throughout the life cycle of earmarked FCPA financial application systems. Key internal accounting controls can be mapped to information security confidentiality, integrity, and availability control measures. For instance, information security application accuracy controls include input edit and validation routines that ensure information integrity.

“View Part I of the Application Protection series here“

Application Protection – Part II

The FCPA codifies bribery of foreign officials as a criminal offense for U.S. publicly held companies, requires accurate financial-transactions accounting, and amends the Securities Exchange Act of 1934. With regard to accounting, FCPA Section 78m (b) (2) documents managerial responsibility for generating and retaining financial information while presenting transactions accurately and fairly, as well as deploying a “system of internal accounting controls.” Furthermore, FCPA Section 78m (b) (5) has been interpreted as requiring U.S. businesses to create and sustain adequate internal accounting controls regardless of an organization’s cost-benefit analysis ratio. This section of the FCPA therefore decrees preventive and detective controls to avoid financial statement fraud or misrepresentation.

“View Part I of the Application Protection series here“

Application Protection – Part I

Legacy law or regulation replacement is a common occurrence within most governments when circumstances appear to discredit legal mandate enforcement. However, the U.S. Sarbanes-Oxley Act (SOX) of 2002 does not supersede the U.S. Foreign Corrupt Practices Act (FCPA) of 1977. In fact, though tagged legacy enterprise governance legislation by some officials, the FCPA has thrived as the basis for enactment of various internationally recognized legal edicts addressing internal accounting controls that indirectly impact information security management requirements.

Contextually, the FCPA applies to U.S. publicly held companies and was adopted in the 1990s by the Organization of American States (OAS), the Organisation for Economic Co-operation and Development (OECD), and the Council of Europe (COE). Concerning international relevance, the FCPA is a frame of reference for most current IT financial application security best practices. Specifically, details demonstrating this law’s influence are well documented in IT financial application assurance and internal accounting control literature.

Digital Rights Management – Part IV

IPR protection requirements shape complex and challenging management issues. Audio and visual material protection is especially problematic due to the existence of the various known vulnerabilities, and there are even suggestions that effective DRM is logically impossible. Common techniques for audio and video file infringement include unlawful interception, decryption, reverse engineering, authentication manipulation, and analog format capture. Therefore, additional information asset protection mechanisms are required to ensure adequate safeguarding controls, such as instituting continuous security improvement plans for IPR information.

“View Part I of the Digital Rights Management series here“