By Tim Serewicz, The Linux Foundation
A cliche too often whispered is that the IT security team is viewed as a warehouse of unwanted staff who always say no. When that happens, the entire organization suffers. Those working on a project avoid involving the security team, because they think they create roadblocks and add no value. Only when the project is ready for general availability release is there a grudging inclusion of the security team; that is, if they are ever included. By this stage there are often massive updates necessary to improve security, much of which could have been prevented or fixed with less time and funding earlier in the project. The entire organization suffers as the most talented team members, those who have the most potential to succeed in a security leadership role, avoid the security team for fear of hurting their reputations. When the need for security is eventually realized, the only answer may seem to be expensive outside consulting.
Changing and improving culture has always been a difficult task for any organization, but in this case there is a path to improvement. First, you have to break down the mentality that security is the responsibility of only the security team and product is the responsibility of the product team. You need to train and equip the security team to understand and be proficient in the entire software development life cycle, because security issues can arise at any point in that lifecycle. It is also important that some of the top technical staff in the entire organization are dedicated to security; if it is seen as a dead end, you will end up with a lackluster security team and therefore lackluster security. The hardest part is handling those unwilling to improve, as the culture may accept that mindset due to previous warehousing.
The second phase is to ensure that “no” is never the first response. Every inquiry should be met with something like “Yes, and here is how I can help you improve the product and security to get it done.” Security teams need to be seen not as a roadblock, but as a resource for both development and operations teams. Once that happens, the security team will become dependable internal consultants for the entire organization.
The next phase is to train the rest of the organization on the basics of security and early implementation of secure practices. This phase will be ongoing, both to handle turnover as well as the need to encourage security considerations for those who don’t focus on the topic. Everyone needs to understand that even if they do not have “security” in their title, it is still their responsibility to ensure that development and operations activities are carried out with an eye toward security best practices. Security should not be an afterthought to be layered on at the end of a project or passed off to someone else — it needs to be ingrained at every step of the process.
While external consultants can be useful for fixing a particular problem, only employing them when an issue arises, or at the end of a project, leaves the organization vulnerable to exploitation. Their use can also minimize the perceived value of internal security teams, reinforcing the warehousing cliche. And when you factor in the high cost of employing consultants, the time and expense of providing training in security best practices to your entire team becomes a bargain — and that is not even accounting for the benefits of reduced risk by incorporating security best practices into all stages of development, deployment, and administration of technology.
When teams are made to understand that their best consultants are those on the security team, and the importance security has across the organization, they will be happy to include them at every step — from idea to release. A great place to start is the free Secure Software Development training series from The Linux Foundation, which includes:
- Secure Software Development: Requirements, Design, and Reuse (LFD104x)
- Secure Software Development: Implementation (LFD105x)
- Secure Software Development: Verification and More Specialized Topics (LFD106x)
Further training focused on security includes:
- Generating a Software Bill of Materials (LFC192)
- Linux Security Fundamentals (LFS216)
- Kubernetes Security Essentials (LFS260)
- Linux Security (LFS416)
- Linux Kernel Debugging and Security (LFD440)
- Kubernetes Security Fundamentals (LFS460)
These courses are designed to help everyone involved in the software development lifecycle learn why security is important and best practices for inserting it at every stage. By taking steps to ensure that everyone on the team is paying attention to the basics of security, and that they trust the experts on the specialized security team to provide more advanced support when needed, you can reduce your risk of attack, while improving your ability to identify issues and recover your systems significantly.
This article was originally published on TheNewStack.