Applications

Safeguarding Assets is an IT Project Management Issue – Part I

Technology-based systems and infrastructure do not occur accidentally. They come into being only after appropriate planning, comprehensive organizing, judicious resource expenditures, and effective managerial support. Top management usually delegates responsibility for analyzing and developing technology-based systems and infrastructure to a designated technology-oriented function. Where top management has not done so; typically, few IT assets have been deployed.

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.

Peer-to-Peer Networking - Part 2

Maybe, experientially, the small branch office with a P2P network has escaped a security incident since deployment. Even so, a functional P2P network unintentionally presents itself as a potential target waiting for someone capable of pulling the threat trigger to introduce a potent security disaster. For instance, at the infrastructure level, attacks can originate from hackers taking advantage of a P2P enabled application to assist spyware or malware in slipping past perimeter defenses and lodging in the background of user devices. In particular, a P2P-agent utilized in communications software can include or hide spyware that collects information about the target system as well as user, then subsequently send compromised information to unauthorized individuals without the legitimate owner’s knowledge. High-Level Data Link Control, Frame Relay, and X.25 protocols have P2P communication modes that can be spyware enabled. Consequently, a P2P network should not be deployed unless effective compensating and mitigating security controls are implemented.

As operational baseline countermeasures to P2P risks, management should document and monitor P2P file-sharing technology to ensure that this capability is not utilized for unauthorized information distribution, display, processing, or reproduction. Furthermore, management should ensure the appropriate encryption is implemented to sustain an adequate telecommunications defense. Lastly, meticulous proactive security risk assessments of P2P networks can prevent inherent IT vulnerabilities from becoming threats requiring incident response resolution.

Peer-to-Peer Networking - Part 1

There are a variety of networking architectures available for deployment. Potential candidates include Peer-to-Peer, Client/Server and Master/Slave. However, Peer-to-Peer (P2P) architectures present unique governance issues to the information security manager when comparable network configurations are considered. Flawed implementations, poor legacy security standards, limited user awareness, as well as lax technical security and administrative practices can form especially lethal combinations that may decimate a positive assertion regarding P2P network access protection.

Focusing solely on access vulnerabilities, as most information security professionals are acutely aware, P2P is normally restricted to share-level security (also known as Password-Protected Share). Archetypical share-level assigned password security provisions two mutually exclusive access attributes (read-only and full) to a file, printer or other network object. Share-level security also normally lacks centralized access control capabilities. Specifically, a user ‘access matrix’ is usually absent from P2P architectures for granular authentication or authorization arbitration. Therefore, increased security risks are inherent with P2P deployment compared to other adoptable network configurations.