Stifled by Another Compliance Mandate?
Seems like every year there’s a new/modified cybersecurity regulation, standard, or compliance framework that thrusts itself to the forefront of our collective psyche. This year, that clearly was GDPR. While the semantics of each vary, the premise (protect data) and overlapping controls are very similar.
The table below is not meant to be comprehensive, but to illustrate this.
Act/Compliance | Summary |
SOX | Privacy and integrity of financial data in publicly traded corporations |
HIPAA | Ensure confidentiality, integrity, and availability of all electronically personally identifiable information (ePHI) |
PCI DSS | Confidentiality of payment card information stored and used by merchants |
GDPR | Data protection regarding privacy and personally identifiable information for all natural persons in the European Union (EU) |
The Corporate Application Compliance Framework
With the right knowledge and planning, meeting the application-driven requirements is easier than most organizations think. This can be accomplished by:
- Align development processes to implement specific secure coding practices that align with corporate policies and compliance requirements
- Create an action plan to address gaps between current secure coding practices and the desired ones
Development groups typically concentrate on delivering functionality and meeting schedules because they perceive that management priorities place these goals far ahead of application security and compliance.
To counteract this tendency, teams need guidance from management on topics such as:
- The importance management places on data security and compliance
- The direct impact software applications have on data security risks
- The business implications of not meeting compliance mandates
In other words, enterprises need an explicit process for translating compliance requirements into actionable steps for IT teams. Because there are few resources for this, I suggest the Corporate Application Compliance Framework, illustrated below.
At the top level, the enterprise risk management (ERM), human resources and legal groups define the global scope and requirements for corporate governance. These are based on company mission, risk tolerance and regulations affecting the organization.
At the middle level, an ERM group, together with representatives of the compliance and security teams, take the corporate security and compliance standards and add detail to create security policies for the company. These are high-level guidelines for operational security and compliance activities that can later be contextualized for specific business units and functional roles.
Typical tasks at this level include:
- Keep abreast of applicable regulations and standards
- Conduct a threat assessment to determine the security breaches potentially most damaging to the enterprise
- Classify data assets to define levels of data sensitivity and identify which business processes store and transmit sensitive data
- Define concrete application security objectives
At the base level, the security and compliance teams help define specific practices for documenting compliance and ensuring they address business-unit-specific regulations and technologies. Standardized practices improve consistency, reduce errors, and facilitate testing. Most importantly, they provide a benchmark against which compliance can be measured.
“Connecting these dots” requires a range of experts to pool their knowledge to triangulate between:
- Applicable regulations and standards
- Probable threats and application-related vulnerabilities
- Application security techniques and coding practices
While coding standards/best practices can vary, the following table summarizes the more important, grouped by high-level requirements.
Corporate Application Compliance Framework
Requirement | Standards | Selected Coding Practices |
Confidentiality | SOX, PCI DSS, ISO 27002, HIPAA, GLBA, FFIEC, Basel lI, CA SB 1386, FIPS, NIST SP, GDPR | · Do not use custom or untrusted encryption routines · Always encrypt confidential data at rest and in motion · Use security approved and well tested cryptographic APIs · Mask confidential data that needs to be viewed in part; anonymize data when possible · Collect and store only the minimal set of data needed · Use a strong encryption algorithm with appropriate key length · Encrypt your backups and secure the encryption keys |
Data integrity | SOX, PCI DSS, ISO 27002, HIPAA, GLBA, FIPS NIST SP, GDPR | · Robust integrity checks to prevent tampering with data · Validate all input and encode all input and output · Follow least privilege principle · Hash confidential data that needs to be validated (e.g., passwords) with a modern hashing algorithm |
Authentication and access control | SOX, PCI DSS, ISO 27002, HIPAA, Basel, NIST SP | · Implement policies that enforce strong password, password expiration, inactivity timeouts and two-factor authentication · Locked-down role-based access control with clear roles mapped to permissions. Revoke rights when roles change · Securely store and transmit authentication credentials · Do not enable or provision for “guest” accounts |
Logging and Auditing | SOX, PCI DSS, ISO 27002, HIPAA, GLBA, NIST SP, GDPR | · Detailed audit trails of users/apps accessing data and resources · Detailed logging on systems that process sensitive data, including shutdowns, restarts and other unusual events. · Event logs and audit trails are available only to system admins and are resistant to tampering · Do not log any sensitive data · Create a consistent error handling architecture that is used throughout your application · Use generic error messages that do not reveal sensitive information to the user. |
Availability | SOX, ISO 27002, HIPAA, Basel II,FIPS 199, NIST SP, GDPR | ·Failover and redundancy built into applications ·Applications resistant to denial-of-service attack with build in throttles and Turing test controls. · Cleanup confidential data in memory and in file systems when it is no longer needed · Don’t fail to an insecure state · Create Business Continuity and Disaster Recovery plans for the application and test them regularly · Backup data |
Change Management | SOX, Basel II, NIST SP | · Source control · Document all changes to the application · Secure access to source code and check-in rights · Implement a code review process where all modifications get validated by peers · Regularly review code and systems changes and their impact with stakeholders ·Create an architecture that you can quickly deploy and roll-back changes in production ·Limit deployment rights to authorized personnel ·Cryptographically sign your builds and validate integrity during deployment ·Maintain a database of “known good” configuration and regularly integrity check your systems for any undocumented deviation |
While this mapping can be time consuming, the more specific and practical the guidance, the easier compliance will be achieved.
Security Innovation has the industry’s largest selection of secure coding courses that map to more compliance mandates and cover all major languages and platforms.