I happened to read the blog “Regulatory Compliance and Software Quality Assurance” by Paul Fratellone. My blog is somewhat an extension to that with respect to software product development/maintenance.
Normally, the compliance related activities are looked upon as boring or inconvenient or an additional overhead. Be it with respect to wearing seat belts while driving a car or having the tire pressure checkup done periodically for the car, they are looked upon as an overhead/inconvenience. But everyone knows the impact of these kinds of non-compliance if an incident occurs. Software product development is no more different and there is a huge risk if the compliance requirements are not adhered to.
This blog emphasizes on the significance of designing and developing compliant (be it regulation through Government/Industry Standards Association/Security Standards) software. The real outcome is not only being compliant and preventing risk, but also there is an additional positive outcome of having built fundamentally sound software engineers, designers and architects.That is the real interesting by-product of being compliant. Also, compliance related processes can be used as a good risk management tool.
These days, irrespective of the domain of the companies (Travel, Banking, FMCG, CPG etc.), wherever there is a commercial payment through credit card, debit card and other form of payments, compliance to regulatory standards and others, such as PCI DSS has become paramount. Wherever there is personal information getting processed, compliance such as EU Safe Harbor Data Protection, securing Personally Identifiable Information (PII) etc. has become significant.
If an incident occurs due to non-compliance, there are unlimited liabilities not only for the business companies but in some cases, depending on the contract, to the IT service providers as well, in case, there is a malicious code or a flawed design which is not compliant to the standards defined.
Considering the Gen Y entering the software programming world, who are multi-taskers, one of the prevalent attitudes has been that, they can solve any problem by googling. So, the problem solving attitude has been with a focus on a given problem, rather than building a fundamental understanding of software engineering as such. For example, when I entered the Software Industry in 1992, there was no widespread internet or Netscape or any browser. (There was only Mosaic browser but it was not widespread). So, we had to rely on books like Magic Garden explained, The C programming language by Kernighan & Ritchie, multiple networking books by Richard Stevens etc. That was the source of knowledge on the fundamentals of how software works along with the operating systems and how to design/architect the same. Because of the volumes of Gen Ys’ joining the industry, we need to ensure that proper culture and training models are in place at the company level and are customized at the project level.
Not only for compliance purpose, but also to build good software engineers out of Gen Y, with good architecting, designing and programming skills, we need to ensure that compliance related designing and coding principles are covered in their training curriculum. Also, the existing engineers will know the nuances of the principles of the architecting, designing and coding.
For example, The Open Web Application Security Project defines how to architect, build and design good software which deals with avoiding DNS attacks, malicious SQL injection, cross-site script forgeries, how to seek and accept user inputs, how and which layer of the architecture, the user inputs need to be validated etc. It also deals with how to handle credit card processing programmatically and from a storage perspective (For example, CVV can never be stored)! It also gives vivid examples for each of the tracks like Java, .NET C# etc. It also explains the fundamentals behind the way of good coding Vs bad coding with examples. It deals with right from architecture to session handling to coding to deployment. The amount of information available in terms of good Vs bad design/coding is enormous and it would be a great learning for the software engineering people.
The other area where the companies need to focus on is about educating the engineers on the usage of open source software. Due to the usage of internet and googling, sometimes, the engineers do not know about the licensing aspects of the open source software. Without knowing those aspects, if they use it in the software that they are building, it might become a big burden on the IT service provider as well as the business company. Free software is not “really” free software. For example, under GNU GPL license, if open source software gets utilized as part of a commercial program, the entire source code of the program should be available to the public on demand. Innocence (of using open source software without knowing its implications on the intellectual property rights (IPR) of either the IT vendor or the business customer) is not going to help. There are instances like the FSF’s lawsuit against Cisco on their acquired LinkSys models. Mistakes are made by even big software giants in this area.
There should be good process in place to eliminate these kinds of aspects as well from any IT services or product provider.
It is high time that all IT service providers and business companies stop looking at regulatory compliance as just a compliance issue, and start treating it as a tool to build knowledgeable and high quality work force.