I’ve worked in large organizations where IT and software was the means to an end by supporting business and I’ve worked in purely technical organizations where software & IT was our business. These organizations both had information security (InfoSec) groups that functioned really well and were staffed with really smart people. In an ever changing security dynamic having an InfoSec department within your organization if your organization is producing software is simply no longer enough, and it’s not because they are incapable or incompetent, it’s their mandate that they execute very well on, so how could they not be enough?
Don’t get me wrong! I really like my colleagues information security. It’s just that the odds are forever being stacked against them & the environment is changing so drastically.
Traditional InfoSec
Traditionally, InfoSec & Chief Information Security Officer (CISO) has had accountability and responsibility for the safety and the security of the entire enterprise. In small organizations, this is still a big job in the true enterprise it’s actually very large. If you really want to know everything, a CISO should be responsible for you need to look no further, then your nearest copy of the CISSP study guide and the 10 domains contained there within. The 10 domains of security for any enterprise organization are:
- Access Control
- Telecommunications and Network Security
- Information Security Governance and Risk Management
- Software Development Security
- Cryptography
- Security Architecture and Design
- Operations Security
- Business Continuity and Disaster Recovery Planning
- Legal, Regulations, Investigations and Compliance
- Physical (Environmental) Security
Each domain has a number of items and tasks and information contained underneath it all, sometimes it makes sense for a CISO to have some help by appointing senior people to lead the activities under certain domains. In the large enterprise organizations InfoSec because they have a responsibility for ensuring the safety of the organization they’re busy with such activities as defining policies for, acceptable use, encryption, E-mail, access standards, both physical and software. In addition, they may be busy monitoring and setting up a SIEM system, monitoring and responding to network traffic, data loss prevention initiatives, performing risk analysis on systems the business is bringing in from vendors, risk analysis on requests from users. Or they could be running scans, etc. Essentially InfoSec has a huge responsibility and not an easy job.
The reason being, InfoSec has to set policies, drive initiatives that apply to the entire organization and then have to respond to the entire organization’s security needs. Trying to define a policy that works for everyone and is easy to use, etc. is a difficult job. Essentially, InfoSec drives the security initiatives and sets the security direction of the organization and responds to all the malware and various attack vulnerabilities such as POODLE, Sandworm, etc. that come up.
InfoSec Gaps
The information security department and guys can be very smart when it comes to security and set standards etc., you don’t need to be a software engineer to implement a SIEM, or respond to patching vulnerabilities, or define firewall security rules, nor do you need to be a software developer to determine what protocols the organization will allow or not. So while an InfoSec individual may be an expert in overall security and know what needs to be done; there is no guarantee or requirement that they know how to get it done, or the implications and reasoning why one solution may or may not work. The reality is even if an InfoSec person comes from a software background they’re going to be too overwhelmed with all their other work to get caught up in the individual details of a particular software application or even worse many applications if need be within the enterprise.
An InfoSec person may live and breath security and not care about anything other than security… That’s not a bad thing unless it’s your CISO. However for an analyst working in InfoSec, this attitude and view point is usually what makes them very good at their job. However, we know as software engineers that software can’t work that way….sure it can be 100% secure and so locked down that nobody can ever use it? However, at that point, what’s the point if users can’t use your software because it's so secure, then it’s not going to make money you’re not going to get paid and there isn’t much point in having a secure piece of software now, is there?
Application Developer Gaps
Just like with InfoSec analysts, there are lots of really smart application architects, designers and developers in the industry today. At my last job, I worked with a number of them, they’re up to date on the latest technology they’re constantly thinking about new ways to solve no problems looking for the best solution and are very good at it. However, they’re focused solely on writing application code to meet the requirements. They may know some information about security but not a lot and secure software usually isn’t on their radar although it should be.
Because these individuals are not security experts, they bring a different worldview to the software space, and they may or may not understand the implications of the decisions or they may implement a security requirement to the minimum standard, or the minimum requirement which may or may not be secure.
About 2 years ago, I read a security standard from InfoSec that said all sensitive information must be hashed or encrypted. The reason the standard was written in such a manner was the enterprise was so huge, InfoSec didn’t have the resources or the people to really enforce one way to do something and there were so many applications each doing things their own way. The problem with such a standard is the application teams said, no problem we’ll use MD5 hashing!!! Now we know that MD5 hashing is incredibly vulnerable and not secure at all, so what ended up happening was MD5 hashing was baked into the application and then became very costly to change, now the organization had a piece of software that was insecure, but complied with InfoSec’s standards.
Trouble Brewing
The white hat security space is heating up both in demand and need because the black hate space is growing so exponentially, thieves and cyber criminals are constantly evaluating and designing new threats and opportunities to attack and cause issues for the enterprise and the problem is only growing. Every time Microsoft puts out a new OS or a new version of Java comes out there over times, there are targeted malware to take advantage of new weaknesses. This in and of itself keeps a competent InfoSec department busy, especially with the advancement of spear phishing and E-mail attacks.
The problem is that these cyber criminals have opened up a second front in the cyber security war if you will and that’s against the applications various organizations are developing themselves. Now your InfoSec department is fighting a battle on one front and depending on the cadence of the enterprise software releases the organization is releasing software potentially opening the back door for a criminal to walk in, or at the very least another surface for a criminal to attack.
Rise of Security Engineer/Architect
I really see security engineering & architecture quickly becoming a profession/career path as someone who fills the gaps between InfoSec and the application development teams. A security engineer’s job is to be a really good technical software developer as well as being a software security expert. Of the 10 domains that encapsulate a CISSP, a security engineer needs to be an expert in four of them.
- Access Control
- Software Development Security
- Cryptography
- Security Architecture and Design
A security engineer is really the, engineer of InfoSec, if the InfoSec department says what needs to get done and sets the security policy, it’s up to the security engineer to determine the how. The security engineer needs to be seen as an equal to InfoSec which is why they need to be an expert specializing in application security but they also need to be a really good software developer to be able to effectively bridge the gap between applications & InfoSec. A good security engineer will have their pulse on the software industry and be able to work with developers/architects designing a solution and then be able to communicate to InfoSec why and how the applications are secure. They also should be imparting their knowledge on their development colleagues.
A Security Engineer should be entirely focused on ensuring the applications are secure, not malware, maybe incident response if called upon. They shouldn’t be working against InfoSec but really are the bridge between InfoSec & the application development teams there’s a real synergy between all three pieces. InfoSec needs to have faith and trust in the security engineer that they are securing and building up an appropriate defense in the application space allowing InfoSec to focus on the entire enterprise.
In this way, a security engineer is aligned with InfoSec that brings a high degree of application development and knowledge to the security table, and in turn brings a high degree of security knowledge to the development table. This allows the InfoSec department to focus on the enterprise as a whole and complements them with a highly specialized skillset in a highly specialized area of the organization.
The post InfoSec is Not enough appeared first on Security Synergy.
Submit an article or tip
