Knock, knock on the door… “Do you have a minute to talk about a report request?” asked the developer.
Security awareness typically focuses on employees – the people working in support, the call center, or with business partners. What about developers? The people who receive requests from the company to execute something – be it a new cutting-edge application, business-driven reports, or efficiency requests so we can do more with less. All of this is great – developers provide significant value to companies.
“With great power comes great responsibility.” Where are developers in the security awareness and training matrix? Oftentimes developers are pressured for being on-time and under budget and security isn’t always top-of-mind.
What about those innocent reports mentioned above? You know, the kind where extracts are pulled from the databases to list whatever it is the business wants to know.
Who are the most profitable customers? Which location is making the most money? Which business partners require a report to reconcile their financials or provide an outsourced service?
These examples are not about SQL injection or cross-site scripting, but rather extracts of data from databases accessed by (likely) internal web applications. If the developer provides exactly what the employee asks for, is he/she providing too much information when there are other options?
Can the extract be provided with masked or truncated data? Can another unique, yet meaningless number be used instead of a social security number (for example)? Are there queries that connect into the database with reusable credentials that could be misused if in the wrong hands?
You get the point. The likely answer is that with the proper structure to the awareness program, these discussions and procedures can be put into place and executed.
There are countless examples where the business provides a request and developers write web applications or reports that allow for too much information when in reality less may be needed. Granted, there are times when this is not the case. But without security awareness with developers, there’s great potential for providing too much.
It’s worthwhile to establish secure developer training and a formal SDLC – no question. The point is that the ability to connect to, and extract sensitive data in business intelligence reporting can be easier to address through an effective awareness program that links into development.
There’s an opportunity to get out into the business and strive to make significant improvements to the data extracts and web applications and it can be easier to achieve than formal secure application development. Both are important of course – the key is to drive awareness and process change into the business by chipping away at areas where there is opportunity for a quick turnaround.
Get the conversation, training, and awareness flowing and the next report extract can contain less sensitive information and make improvements across the business.