5 Training Tips for Secure Software Development

When most people think of software security, they think of the secure software development life cycle. This might involve coding best practices, the use of scanning tools like SAST, DAST, and IAST, as well as penetration tests to identify vulnerabilities in the software.

But the real hard work of secure software development comes after the development is technically done. Of course, software development is never really “done.” Software continues to grow and evolve once it is launched and in the hands of users. But once the software is launched, it’s also in the hands of IT and other members of the organization who might have back-end access to it.

That’s where problems can occur. As the circle of hands on the software expands from the developers to the wider user base and IT support team, each person involved becomes a potential vulnerability. A study by Verizon noted that 90% of data breaches relied on social engineering—in other words, manipulation of the people, not the software. 

In short—one of the most important priorities in the secure software development life cycle has to be training. Not just coding, but training the responsible teams, and even the users themselves, how to interact with the software in a way that preserves its integrity. This includes training pre-launch, as well as reinforcement training after launch.

Data breaches cost a record $1 trillion dollars to the global economy in 2020. It’s worth it to get this right. Let’s talk about five key training tips for secure software development. 

Get Internal Alignment on Prioritizing Training

Before you can get your team on board with essential training, you first need to obtain consensus at the top levels of your organization that training is essential. Some top stakeholders may not want to hear it, especially if they have been extensively involved in the nuts and bolts of the development process. 

The development process may have nearly killed them. The last thing they want to hear about is ongoing responsibilities, or the notion that the software is never really “done.” 

But if any stakeholders aren’t on board, get them on board. You’ve devoted this much effort and resources into a secure software development life cycle—you might as well devote the effort and resources to finishing the job.

Make the effort not only to get internal alignment on the importance of training, but also what to prioritize during training. Aspects of software security training to consider as priorities include: 

• Data Security. This generic-sounding term specifically refers to guarding sensitive data stored within the application’s database or adjacent databases. This could be user data or organizational data. Data security forms a key component of regulatory compliance in many agencies.

• Cloud Security. 80% of application functions will take place in the Cloud. Some security procedures are easier in the Cloud, others more complicated. They definitely deserve separate attention if you have a Cloud-enabled application.

• Risk Management. More of an overarching security strategy, risk management depends heavily on the training of employees, including the mitigation of risks posed by software vulnerabilities.

• Password Practices. Compromised passwords can cost fortunes. Train your employees on effective password management so that it becomes second nature. 

Have Specific Training Protocols for Onboarding

One of the biggest reasons to commit to ongoing software security training is that your team will keep growing—or some people will leave and be replaced by others. When new team members come onboard, your secure software development life cycle is useless if you can’t achieve buy-in and competence in security practices from every new employee. 

Software security training should be mandatory for all new hires. It’s about more than just finger-wagging about the admittedly dire consequences of lax software security practices. New employees need to feel empowered. They are the first line of defense against cybercrime. Don’t treat them like liabilities or misbehaving children—treat them like warriors in the defense of the organization they are joining. 

• Acceptable Use Policy (AUP). An AUP sets forth the acceptable practices for the use of IT assets like the company’s custom software products.

• Access Control Policies (ACP). While an AUP sets forward the standards of use of IT assets, an ACP sets forth the standards for access to the company’s IT assets, including tiered and admin access rules. 

• Remote Access Policy. Most software will have acceptable standards for remote access, which presents different security concerns compared to on-site use of the software.

• Threat Identification. 90% of cyber attacks target the people, not the software. Threats like social engineering depend on credulous, untrained employees. Teaching employees to identify and report cyber threats can drastically eliminate the risk faced by the entire organization.

• Email, Internet, and Social Media Policies. Many threats to company software may come through channels not related to the software, including employee interactions elsewhere on the internet—emails opened, websites visited, social media sites engaged with. Employees need specific training on how their web habits can compromise software security. 

• Data Handling. Many new employees will be trusted with sensitive company or user data. They need to be instructed early and often on the proper handling of that data. 

Once new hires have received their initial software security training, they must have mandatory reinforcement training to keep them on the reservation. Make it a part of the company culture—software security matters. It’s part of the identity of the organization and should be accepted by every new team member.

Have Procedures in Place to Address Emerging Security Changes

We have said it before, and we will say it again—software is not static. It is never really done. Updates and patches happen, new features get released, user feedback gets incorporated. Every change represents an exciting development in the software lifecycle. But it also represents an opportunity for new vulnerabilities to emerge.

Don’t hope for no change—plan for inevitable change by creating procedures to address change and training your team in those procedures. Examples of policies to put in place to cope with change in the secure software development life cycle include:

• Change Management Policy. A change management policy systematizes the dissemination of information throughout the organization whenever a change occurs in the security situation of the software. This could be the result of a new patch or update, added features, or a new security threat. Whatever the change, it doesn’t fly under the radar. All relevant personnel know about it. 

• Incident Response Policy. The next series of policies are policies you don’t want to have to use, but you have to prepare for the bad and even for the worst. The team should be trained on how to respond to an incident, including software security failures that may lead to an incident like a data breach, crash, or cyberattack.

• Disaster Recovery Policy. A disaster recovery policy sets forth the procedures in the case of a massive failure of cybersecurity. If the disaster is big enough, the next policy may come into effect.

• Continuity of Business Policy. A continuity of business plan is meant to prevent the business from closing permanently after a data breach, maintaining essential hardware and the chain of command in the event of a catastrophic software security failure.   

Understand Any Relevant Regulatory Issues

Regulated industries like finance, medicine, and government must comply with strict regulations in the development and management of their software solutions. Team training needs to address this, since failures of compliance may result in heavy fines and even forced closure. 

Regulatory controls that may intersect with secure software development include:

• ISO 27001. An international standard for information security management, maintained by the International Organization for Standardization (ISO) and the International Electrotechnical Commission (IEC). 

• PCI DSS. Standards for the handling of payment cards, established by the Payment Card Industry Software Security Council, necessary if your software solution or adjacent databases store credit and debit card information.

• CIS Controls. The Center for Internet Security maintains eighteen security controls as part of a uniform standard for internet security. 

• OWASP. The Open Web Application Security Project (OWASP) maintains security standards applicable to open-source applications, or applications that use open-source code.

• HIPAA. The Health Insurance Portability and Accountability Act includes standards for the handling of patients’ sensitive medical records.  

Make Time to Revisit Training at Regular Intervals

Training should never be a one-time thing, especially for something as important to organizational health as software security. Your software security training plan should include regular refreshers and updates to the training, at least once a year or whenever a major change comes about. 

The “revisit” training can bring the team up-to-speed on any changes in the security environment of the software. They can also act as helpful reinforcements, not only of the concepts themselves but of the culture—a culture that cares about software security and takes it seriously. 

Conclusion

Secure software development is not just in the hands of the developers. Eventually, it becomes the responsibility of everyone in the organization who will touch the software. Training your team in software security is a critical component of secure software development, preparing them to shoulder that responsibility with poise and aplomb.