For several months now, I have been proactively identifying risks and vulnerabilities within my organization. Some have been easy to fix; I just had to write some new policies, convince our facilities department to issue picture ID badges or replace our firewalls. Others require some heavy lifting. And it can be tough to persuade co-workers to pursue security objectives, especially in a small company with a tiny security staff.
One potential security weakness that I want to address but that I can’t do on my own involves the architecture of our application programming interface. Our API architecture was developed more than 10 years ago and was never modernized. When a user wants to write an API to help a customer interact with our application, we issue two user IDs and passwords. One credential is used to access a shared API gateway, and another credential is used to access the specific customer’s data. Maybe requiring two different passwords seemed like a strong security measure a decade ago, but it doesn’t impress me today. Passwords can be compromised.
A more secure and modern method for allowing API access is to use OAuth, an open standard that uses access tokens issued by an authorization server. Moving to OAuth will require a great deal of engineering, but even more daunting is the amount of change management needed. We will have to retrofit everyone in our customer base that is currently using the legacy API and change all sorts of documentation and enablement processes. All in all, it’s a huge effort.
I also want to roll out an application that will let customers, support personnel and other organizations assess the security health of their configurations. We offer several configuration options to our customers, including password complexity, session timeouts, lockout, multifactor authentication, single sign-on, and roles and permissions. A health check application would allow customers to identify both weaknesses and opportunities to enhance security. Our support organization could use it to encourage customers to enhance security controls.
So a strong case can be made for developing such an application, but it also will require a lot of work from many teams, such as product management, engineering and support. Those folks, of course, are all focused on daily operational activities and other priorities identified by management.
The good news is that the executive staff have given me their blessing to pursue both of these initiatives. But that isn’t the same as allocating the necessary resources. So how are we going to get them done?
Well, if the problem is that the people I need to contribute to these projects have no incentive to do so, then we need to give them an incentive. The tool available to do this is bonus payouts. The company measures performance by determining how well employees have met the various objectives laid out in their performance reviews. Progress (or lack of progress) in meeting those objectives helps determine how large each employee’s bonus will be.
I have talked upper management into creating two objectives for key managers within the product management, support and engineering departments: “Develop a plan to modernize API architecture” and “Identify requirements for a security health check application.” They’re in my objectives as well. Now we all have a vested interest in completing these projects. Next quarter, I’ll expand the objectives to move the initiatives along, and so on until completion. It may take several quarters to complete both of the initiatives, but it’ll be worth it.
This week's journal is written by a real security manager, "Mathias Thurman," whose name and employer have been disguised for obvious reasons. Contact him at firstname.lastname@example.org.
Click here for more security articles.
This story, "To get new initiatives done, money talks" was originally published by Computerworld.