SecureState Blog

Read SecureState's award winning blog.

Designing Applications in an Over-Regulated World

Interpreting development specs is challenging enough, but writing code without analyzing the regulatory business ramifications rarely ends well. Typically the process assumes your business leaders and partners understand the regulatory environment, the impact to application functionality, and that they can successfully articulate the requirements to the development team. But often the message is muddled, because of a lack of understanding. So put on your red cape (blue tights optional), and read some compliance strategies to take your career to the next level.

[WEBINAR]  PCI, HIPAA, GLBA and an Acronym Soup of Regulations…Can’t we just develop anymore?

Start with a new paradigm: development teams offering secure coding options, privacy requirements, and sufficient detail to obtain executive buy-in.  In recent years, we have seen development work outsourced. Now more than ever adding value beyond sitting behind your keyboard churning out lines of code can provide you with upward mobility and more importantly job security.  Outsourced developers often lack the business acumen and understanding of the organization’s core business model to provide this insight. Investing a little time to determine laws and regulations that apply, industry best practices, and consumer expectations differentiates your skill-set in an increasingly commoditized industry. To jump start this process continue reading for a pragmatic approach to building privacy and security methodologies into your code development process and application build, differentiating yourself, and doing the right thing for consumers who trust you with their sensitive data.

 

#1 Know the Rules

Complying with numerous federal laws, international and domestic, plus state law, industry standards, and contractual obligations can be difficult. Unlike the European Union and other countries with robust privacy laws, the U.S. lacks a single regulatory framework regarding securing consumer data. Filling the void, albeit insufficiently, are a patchwork of industry specific regulatory requirements, such as the Graham Leach Bliley Act (GLBA);  Health Information Portability Accountability Act (HIPAA) , Payment Card Industry (PCI), Sarbanes Oxley (Sox), etc. Adopting development practices to adhere to a single framework is often challenging for developers who typically do not have, nor want, a legal or compliance background. Using a generic framework, such as Generally Accepted Privacy Principles (GAPP) will position your code well for compliance with numerous regulations, but a more focused regulatory approach may be needed based on risk.

 

#2 Get Executive Buy-In

Recall the old project management 101 three legged stool: scope, resources, and schedule? For example, if you add scope (e.g., secure coding requirements) it will consume more resources and/or take more time to code and test. You need to show how this improves risk posture, customer experiences, reduces cost of ownership and/or better positions you for regulatory compliance. Articulating this message will ideally result in buy-in and career advancement. Developers who can think beyond just writing code move beyond the commoditized developers. Add value and increase your value!

 

#3 Don’t Boil the Ocean

Crafting “guiding principles” from the applicable laws or generically from GAPP can begin the process. Small wins will reinforce the return on investment (ROI) compliance posture argument discussed in executive buy-in. For example, questioning why an application accesses an entire table, instead of just the needed records and better yet required fields within those specific records. Introducing these concepts during a maintenance release gets the project management team and business owner thinking, and leads the discussion along the lines of industry relevant privacy concerns.

 

#4 Know Where the Data Lives and Breathes

Network diagrams are a great start for documenting data flows and where data is stored, but it needs to include business logic, such as, who has access to the data, is the data access role based and can it be downloaded, printed, etc? A brief whiteboard session can identify and uncover downstream data stores with weak or missing controls. The development team can then make risk based decisions to include additional controls for these data stores.

 

Privacy by design and security by design, in the past, have been considered niceties, but given the number of breaches each year that are published in mainstream media and social media, the cost of those breaches, and the regulatory scrutiny, these are now manifesting themselves into development requirements. A data breach can result in penalties, public castration, and even legal action (e.g., you are contractually required to protect data that somehow is breached). If the business owners are not driving this change, the development team can and should be the voice of reason. So if your application creates, accesses, processes, or transmits sensitive consumer information consider privacy by design. It is good for business, a good career move, and more importantly good for the consumer – we are all consumers.

 [Watch Now!]  PCI, HIPAA, GLBA and an Acronym Soup of Regulations…Can’t we just develop anymore?

Sample List of Regulations/Industry Best Practice Frameworks