Bridging the Gap: The Need for Technical Expertise in Auditing Records Management and Security Controls

Evaluating Internal Controls for Records Management

To evaluate how management establishes adequate internal controls for records management, an auditor would first consider the information security policy, privacy policies, standards, and procedures. Evaluating the policy against laws, regulations, and best practices provides insights into access control, data protection, incident response, and user responsibilities. However, an auditor cannot adequately assess the adequacy of records management and the records management classification processes for the IT organization. While data classification helps auditors identify the required level of protection and handling, the auditor checks off that the organization has access controls and other policies. However, auditors do not typically verify the correct technical implementation of these controls. This oversight creates potential security gaps when technical implementation during an audit is not validated. The auditor is not a software engineer. They lack the technical expertise to understand and fully evaluate the implementation details. This oversight puts the entire organization at risk.

The Role of Software Engineers in Audits

A software engineer is trained to be very detail-oriented. When entering an auditing environment, the software engineer will see that auditors keep track of many things but do not address the granular implementation details. An auditor often relies on the software developers who created these systems for their expertise. If the software engineer, for example, implements an authentication mechanism improperly, no one will know it was done incorrectly because the auditor is not a software engineer. The auditor will likely talk to the manager of a software team to verify access controls but will never actually talk to a software engineer who knows the implementation. Auditors do not test every single control. They focus on compliance with pre-selected policies and standards instead of implementation. This gap leaves management in charge of implementing and maintaining controls.

Case Study: The United Health Data Breach 

The recent United Health data breach due to the lack of Multi-Factor Authentication raises essential questions about the competency of auditors. Multi-factor authentication was already likely a control that auditors frequently signed off on. Many compliance frameworks and security standards, including CIS Controls, NIST SP 800-53, and HIPAA, require MFA. While the auditor likely checked the policies, configuration settings, and user authentication logs, they likely relied on management assertions. They had no actual understanding of what they were signing off on. This breach affected more than 8 million people in the United States.

Real-World Example: Facial Recognition for MFA

The difference becomes apparent when studying the CISA study guide because it is not technically accurate in some areas. Authentication is based on three things: something you know, something you have, or something you are (biometrics). For my MS Software Development capstone, I built a multi-factor authentication service that utilizes facial recognition with TensorFlow. While facial recognition for MFA has some fundamental conceptual flaws, such as a user authenticating an account with a picture from Facebook, the intent was to learn more about facial recognition. Facial recognition has come further than signature analysis as a dependable form of biometrics. Check it out and play with the demo: https://biometricbarrier.com/.

The Importance of Encrypting Biometric Data

Biometric measurements look at different parts of the human body, but they are all very similar in how they operate. They build a map of vector data that is unique to the original scan, preserving relational meaning between data points. Biometric data should be encrypted just like any password should be encrypted in a database. A suitable encryption algorithm will include a hash and a salt. 

The Role of C-Suite Executives in Security

The C-suite executive's job is not to prevent data breaches or improve the quality of life of an employee but to make money for the stakeholders. This approach represents a significant security risk because C-suite executives may not prioritize employee well-being, which can affect the company's security posture. Auditors are employed by C-suite executives to ensure compliance and ethical behavior, but this does not always guarantee that C-suite actions align with security best practices and ethical behavior. Security improvements often only occur when they are financially justified, no matter who it hurts. This means there is an acceptable level of risk, which includes potential data breaches, as long as the cost of a breach is perceived to be lower than the financial gains. C-suite executives should prioritize security and employee loyalty to reduce risks and protect the general public.

Challenges Faced by Software Developers

Part of the problem with security mistakes is that software developers are under pressure to perform complex tasks with deadlines under management and executives whose primary focus is the company's bottom line. Software developers become software developers because they are passionate about what they do and enjoy it. Sometimes, they enjoy the complexity of being detailed in their software programming at their own pace. In the corporate environment, a software developer under pressure will make mistakes. Test, QA, and code review can improve catching those mistakes, but this is not foolproof. There are different levels of software developers with different technical capabilities and backgrounds. 

The Need for Technically Proficient Auditors

While auditors attempt to verify compliance with policies and standards, their inability to understand the technical implementation details leaves significant security gaps. These gaps can result in overlooked vulnerabilities, as seen in the United Health data breach. Organizations should ensure that technical controls are effectively implemented and maintained. They must prioritize security and support their technical teams to mitigate risks effectively. Without these safeguards, organizations will continue to suffer until they raise the auditing standard to include more of a technical background for protecting the American public.

Key Management and Storage Best Practices

While the book teaches that key wrapping is used to protect encryption keys from disclosure, key wrapping is only effective when data keys are not being used on a production server and are only being stored in a digital format. Any experienced engineer would tell you that using key wrapping to protect an encryption key requires another encryption key that is still vulnerable to any attack the original key is vulnerable to. The only safe method of protecting an encryption key for data storage at rest is to not store the encryption key in a digital format. Instead of using key wrapping, encryption keys should exist only in protected key stores, such as Gitlab and AWS Secrets Manager. These key stores allow authenticated access to keys in pipelines and production servers to keep keys secure at rest and in transit. In this way, you could fail this question on the CISA exam, but it would be because you know what you are talking about. Encryption keys should be rotated at least every six months.

Secure Communication Over Public Networks

The primary challenge of communicating sensitive data over public networks is not knowing who else may be listening to your traffic. It would be simple to say you need encryption, but encryption relies on both parties knowing the decryption key ahead of time. In transmitting the key to the other party, the middleman will also receive the key and will gain access to any encrypted communication. The Diffie–Hellman key exchange is a mechanism for two parties to agree on a mutual encryption key without a third-party eavesdropper gaining access to the key. Diffie–Hellman key exchange is used in SSL/TLS, SSH, and VPN technologies to establish secure communication.

The Role of SDLC in Ensuring Security

The System Development Life Cycle model is crucial for laying the groundwork for a secure system. While the Diffie–Hellman key exchange is embedded into existing secure communications protocols such as TLS, SSH, and VPN technologies, there are some considerations when these protocols are insufficient for communication. In these cases, an auditor would need to know precisely how they plan to establish secure communications and what specific technical mechanisms are required to facilitate secure communications. The SDLC design must specify the mathematical basis for adequately conducting a Diffie–Hellman key exchange protocol. Sufficient primary key sizes and generators must be defined to prevent attacks.

Why Management Should Not Oversee Encryption Implementation

Management overseeing encryption is ineffective because of the complex mathematical nature of encryption. Encryption is the product of many mathematicians solving complex mathematical problems and is unsuitable for management to determine because they are not mathematicians. While management may know that encryption is necessary, the implementation details of encryption and security should be left up to the SDLC, which includes rigorous testing of encryption mechanisms, ensuring their viability in the application they were selected for. The maintenance phase of the SDLC ensures that encryption mechanisms remain effective and up to date.

Implementing Access Controls and RBAC

When configured appropriately, ACLs implement internal access control rules within application software based on the principle of least privilege. The principle of least privilege extends beyond technical implementation details. It relies on active revision by management to ensure employees only retain the level of access they require to perform their job functions. Role-Based Access Control manages collections of user permissions based on the user's role. RBACL used in an inappropriate scenario where roles evolve, such as a startup, is ineffective at managing the principle of least privilege.

Conclusion

The integration of technical expertise in the auditing process is crucial for bridging the gap between policy compliance and practical implementation. The case of the United Health data breach highlights the dire consequences of auditors lacking the necessary technical knowledge to validate security controls effectively. By involving software engineers in audits, organizations can ensure a more thorough evaluation of security measures, thereby mitigating risks and enhancing overall security. C-suite executives must recognize the importance of technical proficiency in audits and prioritize investments in skilled auditors to protect sensitive data and maintain stakeholder trust. Ultimately, elevating the auditing standards to include technical expertise is not just a matter of compliance but a vital step towards safeguarding the organization's integrity and security.