Stifled by Another Compliance Mandate?

 
How to Positively Use Compliance Mandates to Drive your Security Standards

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: 

  1. Align development processes to implement specific secure coding practices that align with corporate policies and compliance requirements
  2. 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:

  1. Applicable regulations and standards
  2. Probable threats and application-related vulnerabilities
  3. 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. 

SECURITY INNOVATION  Course Offerings

 

 



You might also like
Leave A Reply

Your email address will not be published.