Back when I started programming, we didn’t build technology to be secure – there was little to no threat against those applications, and we essentially builtthem to meet business needs specific to the company.Most of these applications lived insideeach companyand were protected by its walls.
Well, those days are gone – and today information technology security is a top priority for every company becauseof constant,growingand evolving threats. Now called “Non-Functional Requirements,” what the application doesn’t do is equally as important as what it actually does.
Building and running applications with security as a requirement is a change not just in technology or process, but in our own behavior.Today’s developers must learn and understandhow to properly secure applications, because if development isn’t planned well, or if it’s met with resistance from those involved, thenecessary changes can significantly add to the development timeline.Product owners can help manage expectations by communicating the risks that would be eliminated by building in the right security from the outset.
Applications are built to run, not to fail. But of coursethey do fail, and for many different reasons, and while failures related to security vulnerabilities are preventable, they require a commitment to change how applications are built and run.Without this change, security will continue to be an after-market add-onwhich limits the options available and,in many cases,causes friction for the application users.
Enter the Program Management Office! The people who manage projects are accustomed to change and can be great change agents. Who better to have as a partner than the people who build what goes into the project plan and schedules? With Project Managers armed with details of what needs to be included to meet security goals, the plans are created to include security from the start.
So how can we secure apps as they are built?
1.Properly protect keys and other secrets in code repos
2.Develop and test disaster recovery plans alongside the development of the app
3.Build logging integrated with a SIEM
Identifying potential failure points and recognizing the signals of failure, or preferably pre-failure, will also help identify what additional functionality is neededin order for applications to be fail-proof.Once the app is up and running, it should be monitored for signals of failure,alerting based on criticality, and self-healing where possible. Planning adequate and regular time for patching is one of the easiest ways to reduce risk by eliminating vulnerabilities,but it is not truly easywith legacy hardware and software and 100% uptime requirements.
It’s time to draw the line in the sand and say,“from this point forward we will build security into our applications from the start.”Without change, companies will slip further and further behind the ever-evolving cyber criminals.As security professionals we can make the first move to build strong partnerships with the development teamswith thecommon goalof protecting our applications and infrastructure.