When you’ve worked in the security space long enough with various organizations, you quickly discover there isn’t a shortage of security vendors that are willing to help you and your organization with their wonderful security products, processes and services. I can honestly say after talking and working with a number of high profile security vendors, who also offer numerous free publications or white papers, I’ve never met a shady security vendor. This is not to say that they don’t exist, I am sure there are some security vendors that exist, who are shady, however my interactions thankfully have been limited to the above board ones. An interesting phenomena is that these security vendors are ever increasingly trying to fill security gaps within IT organizations. While security vendors have their place within a comprehensive security solution, I find this trend very disturbing.
Security Intelligence
Security vendors are always going after a bigger slice of what I call the security gap pie. The security gap pie is a pie that is baked when an organization uses IT or creates technology through programs, and they don’t employ or follow proper security policies and procedures. The security gap pie is filled with an organization’s general lack of security intelligence. I consider security intelligence to be the profile of how security aware an organization is from the CEO right to the CO-OP/Intern. The security intelligence gap, and therefore the pie, has grown increasingly larger over the last decade for the following reasons:
Applications are infinitely more complex than they were a decade ago with a variety of many different technologies, frameworks, SAAS, all working together. Trying to maintain effective security awareness around all the portions an application touches, works with and uses is simply insane.
It’s difficult for security to be considered a priority when it’s not seen as creating business value, or seen directly as a cost. Organizations tend to de-prioritize in favor of features that will actually make money into the next release.
Security is time consuming, especially if it’s bolted on and not baked in from the get go, all too often, there is an attitude ship first – secure later.
Organizations don’t view a secure software product as a quality software product, I see security bugs, treated differently & less urgently then feature bugs.
Post secondary institutions creating software engineers rarely put a focus on software security or secure coding techniques and building security in. For the first 3 reasons listed here, developers don’t have time to focus on security and therefore don’t learn it.
Security vendors work to create an atmosphere whereby whatever your security need is, they have a tool, service, product which can fill that need so the organization doesn’t need to worry about it, which means it’s technical folks don’t learn security properly….it’s almost a self fulfilling prophecy.
Unfortunately, organizations sometimes feel that it’s cheaper to solve a problem by throwing money resources at it than developing intelligent folks who are experts in the systems the organizations maintain into security aware individuals.
- Complexity
- Security isn’t a priority
- Schedules
- Lack of Quality
- Knowledge
- Security Vendors
- Money
I am not making a case for every technical person to become a security expert, such a request would be absolutely ridiculous. We can’t all be experts at everything we do within the technological space. Nor am I saying that an organization should never use a security vendor or security tools. I really do believe there are a lot of excellent tools and vendors providing some good services, however they have their place.
Quandary of Security Tools
As I said, security tools are great, however a tool is just a tool. If one were to build a house, knowing all the tools you need to build a house and even how to use those tools properly is simply not enough, you still cannot build a house. At the very least, you need a blue print of what the house is going to look like so you know that you’ve gotten it right, moreover however if you have no idea of how to build a house, chances are you’re going to make a lot of mistakes.
So too, just having a security tool and knowing how to run the tool is not enough. I’ve seen security tools that performed all kinds of analysis, on static/dynamic analysis on code, penetration testing, vulnerability scanning. However at the end of the day, they’re just a security tool. The user needs some security knowledge to be able to interpret the results, lots of tools will give you a false positive on a security issue that, is in actual fact not a security issue. This is a dangerous places for someone to be in for a couple of reasons:
If you spend a long time investigating and chasing a false flag for a security issue just because a tool says it is a security issue, you’ll potentially cost the company money in your salary and that of anybody else who is enlisted to help you. This further drives the stereotype security only costs money.
If you can’t clearly explain and answer challenges to managers or senior engineers about that vulnerability and you take the position that it needs to be fixed because the tool says so, a Sr. engineer or security person may prove it’s not a security issue, in an effort to save the company money or them work. Then, you’ll not only suffer a reputation damage but the results from the tool will constantly be questioned.
- $ Money $
- Reputation
Whenever I use a security tool from a vendor, I use the tool as a starting point for an investigation. It’s almost like the tool is police sniffer dog, the dog doesn’t solve the case for the police, the dog only sniffs out the starting point of an investigation. So too tools are a starting point, they can sniff into the code, or compare against a huge list of CVEs. Therefore, my methodology when using a tool:
I look at the results and potentially the recommendation of the tool.
I seek to further gather more evidence on what the tool is reporting so I’ll go off and search Google for more information potentially reference CVEs to completely understand the vulnerability I am to report on.
Write an exploit case against an environment that represents production as closely as possible. By production, I am not talking about simple external production, internal environments are production as well. The firewall should never be counted on for protection.
I’ll try and run the exploit here the results are really agnostic, a positive result, and a successful exploitation is important because it needs something that needs to be fixed and repaired to better secure the systems. This step also provides a quantitative result to know when the issue is fixed, when the exploit flips from successful to unsuccessful then the issue has been successfully mitigated. However, a negative result is just as important and valid, a negative result means that the tool reported a false positive. It’s important to document this as well because it is useful information to explain to management, if they ever see a tool’s output, or when renegotiation occurs with that vendor, you might consider if there are better solutions with less false positives.
- Results analysis
- Issue Analysis
- Exploit Case
- Exploit Test
Now you need security intelligence to follow that methodology, and security intelligence doesn’t equal programming intelligence, although programming intelligence can help, however usually where a vulnerability is a CVE, in an existing system, there is are well documented exploits available through a variety of tools such as Metasploit. Even where a vulnerability is reported in custom code such as XSS or CSRF, there are tools like OWASP ZAP to help exploit & test that, however again using a tool to exploit something in custom code again you have to be aware it is a tool.
Where programming knowledge helps is when you have to craft your own exploit to be definitively sure that an issue is exploitable or not. I personally like to use Python for this, it’s quick and easy. However in the absence of Python, wiping something up in .NET can be relatively easy as well.
Tools are great, and I really like some of them and the capabilities in them, however a tool can never think and therefore cannot replace intelligence in security issues.
Security Vendor Services
More and more, I am seeing security vendors who are more than willing to do the analysis for organizations and provide your organization with reports, recommendations and help your engineers fix the issues. I do see some advantages to this type of service, in a limited scope. The problem with this type of solution primarily is that vendor relationships can turn sour, and it often doesn’t take much. Organizations I’ve worked for have walked away from vendors, great products, because senior managers couldn’t agree and got into a tiff. The problem when relationships break down and given enough time they will is that, your organization doesn’t have that knowledge in house. When the vendor leaves, they take that knowledge with them, sure perhaps they’ve imparted some old knowledge but the newest and the most up to date information isn’t available. This could actually harm the organization leading to questions without answers and actually increase the security knowledge gap.
So too an organization should never be drinking from the hose of a vendor. I would expect my engineers to have enough knowledge to stand up and question, challenge the statements from the vendor where appropriate. However, you need some degree of security knowledge and awareness to achieve that.
Bottom Line
There’s a lot of great programs, tools, services and vendors out there. This does not alleviate an organization from its responsibility to be security intelligent and have some of that intelligence in house for its own protection and well being. A organization should attempt to ever be increasing the security knowledge of everyone from the CEO -> CO-OP/Intern and if you’re not and relying solely on vendors… it’s time to change.
The post Case for Security Intelligence appeared first on Security Synergy.
Submit an article or tip
