Security blindspots: websites, network architects, and third-party code
Even with the daily occurrence of breaches, some organizations are not thinking about security, especially those enterprises for whom a large percentage of their revenue comes directly through the website. Many companies that do worry about security, think of it in terms of restricting internal users from accessing what might be potentially risky sites.
Worrying about vulnerabilities from internal users or third-party code, however, is moot if security is not part of the network architecture. Jim DelGrosso, senior principal consultant at Cigital, said that whether network architects are taking security into account when building their websites depends on the organization and how mature its security program is.
"In the financial space, enterprises think about it all the time, but in other areas that are not bound by strict governance, it's not as prevalent. With a lot of the larger enterprises, it is absolutely on their radar," DelGrosso said.
At the design level, keeping things segregated and defense in depth are the best ways to strengthen security. "Security controls layered in such a way that just because I got through some cross site scripting doesn't mean I can get anywhere else," said DelGrosso, "and they need to think about this upfront."
Rather than making security an afterthought, network architects should be thinking about the layers of controls that will create a safer environment.
Chris Olson, CEO of The Media Trust, said, "Architecture is hacked all the time without even realizing it. Every enterprise needs to be monitoring their website, but they don’t. They check the 10 percent to 20 percent of source code that is their own, what they are ignoring is the 80% via third parties."
[ ALSO ON CSO: How to achieve better third-party security: Let us count the ways ]
Whether the code that is written by the enterprise or the third parties poses more risk seems to be up for debate. Some contend that self-regulating open source libraries are less likely to contain vulnerabilities because they've been examined by so many sets of eyes. The code that an enterprise writes, though, is self owned and more likely to pose security risks because it's not been tested as thoroughly as that written by third parties.
Olson said, "Third parties check code, but once it’s put into the content management system, it’s then rendering on the client side and that company that provides that code is no longer looking at it. If that company is attacked, there is no control because it resides in the CMS. The predominance of malware delivery on the web comes from this."
Where the vulnerabilities lie may not be as important if network architects are security- minded when designing their websites. Thinking about security, then, must extend beyond the components of the enterprise website and extend out to testing third-party code.
In a blog earlier this year, The Media Trust wrote, "Considering more than 78% of the code executing on enterprise websites is from third-parties, IT/website operations departments cannot truly control what renders on a visitor’s browser. This inability to identify and authorize vendor activity exposes the enterprise to a host of issues affecting security, data privacy and overall website performance. And, your website isn’t immune."
While it's easy to look at that larger percentage and agree with these findings, Michael Borohovski, co-founder of Tinfoil Security said, "The vast majority of time, companies are getting exploited with the code they wrote. Big companies write a lot more custom code than small companies, but if you do have some combination of first and third, it’s more likely that you will be hacked on firstparty."
While there are undeniably breaches that have occurred because of vulnerabilities in third-party code, more often than not, Borohovski said, "You have outdated software. You didn’t update for six months."
President Franklin Roosevelt's sage words in his first inaugural address, "The only thing we have to fear is fear itself," apply also to today's digital enterprise and cyber security. Borohovski said a lot of companies struggle with network security, web app security, and third party/open source security.
"For each of these, you want to develop a culture of security," said Borohovski, "which doesn’t mean a culture of fear or lack of innovation. You innovate more rapidly because you are trying to write more bulletproof tools. If you don’t have your developers thinking about security, anything they write can be used by an attacker."
Eliminating that fear, said Borohovski, is one step toward prevention. "There is this idea that security is difficult. For attacks led by state sponsored actors, that is true. For vast majority, though, it’s not true. A lot of attacks can be prevented by any developer with the right tools and training," he continued.
Whether they are using software that they wrote or didn’t write, digital enterprises run the risk of having vulnerabilities. "When the open SSL vulnerabilities happened, like Heartbleed, it affected almost the entire internet. That was 3rd party software that no individual at any company wrote. It hadn’t gone through any rigorous security testing," said Borohovski.
In that example, the belief that many eyes is better was not true. "Had they gone through some basic security testing," said Borohovski, that might have been avoided.
For any enterprise, what they never want is to find themselves in a situation where they don’t know where the code they are running is coming from. "Dependency chain is a big deal. Is this an enormous pain Yes, without question. There are tools that will help with this, and admitting you have a problem is the first step," said Borohovski.
A wide range of tools can address these problems in both reactive and proactive ways, but Borohovski said, "Focus on the third-party software as if it were something you wrote. Test for vulnerabilities much like you would any other code that you wrote. Third party that’s open source or from other vendors—tracking solution or anything like that—are a potential surface area for vulnerabilities."
Chris Weber, co-founder of Casaba Security, said that it usually takes something breaking before somebody sees it. "The entire dependency chain with third-party code can become a dangerous proposition and the dependency chains can become quite large," Weber said. Some dependency chains become un-maintained as they can quickly branch out exponentially.
Often times with third-party code, they don’t understand the internals, but with the code they write, they understand it, so they have better visibility into their own code, so it's a good habit for the enterprise to evaluate their use case and requirement for that code, said Weber.
"Any time you take a dependency from a third party, you’ve given up some control of your application," Weber continued. Rather than abdicate that control, it is better to ask, "Do we really need this How long will it take us to build"
Understanding that security has no perimeters requires training and a shift in culture. Finding issues in both the first- and third-party code is not a singular act. Security is an ongoing process, and one that needs to be at the forefront of everyone's mind from the architects to the end users.