Building IT software isn’t always the most secure process. The reason for this is simple economics. Companies can’t always afford to build in the security features software needs to be secure.
Let’s walk through a typical IT software project.
As the IT software project is planned out, the security of the software
and the data the software contains is accounted for. But after the initial design of the software comes budget planning. There’s almost a 100% chance that the budget requested by the developers isn’t going to be approved by management. Management typically approves somewhere from 50-80% of the requested budget. This means features need to be cut. The business unit that requested the project will want to keep most if not all of the features they requested. That means the development team is going to need to find somewhere else to cut. Something has to give. In typical cases, the best options for securing the data and various security tests are going to be cut. This means that data that was going to be securely stored encrypted will likely now be stored in plain text. Security testing on the software isn’t going to be done at all, or if it is, it’ll be scaled way back.
While these types of cuts are not uncommon, as IT leaders, we need to make the business case for investing in enhanced security. We need to demonstrate that budget cuts in security
end up leading to software that’s less secure than end users deserve. From a business perspective, this leaves the company open to potential data breach issues and the remedies that the states and countries the software is operated in are subject to. In the United States, if the software customers are in California or Massachusetts, there are some data protection laws in place that cover data breaches and data encryption.
The issue with data breaches is that you can’t fix the cause of the problem after the fact. Once customer data has been released to unauthorized parties, it doesn’t matter how much money the company spends or what they do to improve the software to ensure a breach doesn’t happen again. At this point, it’s too late—the customer's data has already been breached, and it’s in the hands of people that shouldn’t have the data. There’s no getting the data back out of the public eye. Once it has been released, there’s simply no putting the genie back in the bottle.
As IT professionals, we need to be building software that isn’t easily breached so customer data isn’t released. The fact that in recent years we’ve heard about problems like databases having blank passwords with millions of customers information sitting in them or files sitting in cloud services with no security is just inexcusable.
While budget will always be a major consideration, security also needs to be a driving factor as we consider software development. We shouldn’t have databases without passwords—it doesn’t matter that the default is no password. We shouldn’t have cloud-based file shares with millions of customer records sitting with no security. Once these breaches happen, there’s no getting the data back.
We have to build more secure platforms and software that don’t have simple, easy-to-correct issues in their configuration. The more we can ingrain this thinking into our organizations, the better off we all will be.