The four biggest security myths for software development companies
Shatter myths about security and apply proven practices to boost your business
Among software development companies there’s a common misconception about security and how to approach it. This project phase doesn’t lack its essential meaning but comes after the project is successfully established on the market, bugs are fixed and developers have some extra hours to devote to security findings.
Today we disclose the most popular security myths that haunt software development companies and shed some light on practices and solutions that will help in dealing with potential risks.
1. Security is not a big deal
There's an old saying that you can't have it all. From the perspective of software development, it is usually believed the team cannot foresee all details and sometimes, have to sacrifice things. For example, if you pursue the goal of a fast product version delivery you'll likely have to turn a blind eye to product quality to some extent. However, let's be straightforward, geographically spread development teams strive to meet deadlines, deliver quality functionality while the security is underestimated and goes as an afterthought.
Solution
In a nutshell, include security into system requirements and software development lifecycle. Give software security requirements as much priority as it's given to business and functional requirements.
Compliance with security constraints would lead to a strong software system and help to avoid any potential work disruptions caused by dangerous attacks
It is also advisable on this early stage of planning to evaluate system assets and concerns that could be identified alongside. For instance, if your system operates data of a medical center you would probably have to focus more on potential threats to confidentiality and authenticity of patients' records.
2. Embedded development is less sensitive to malicious activity
Embedded development projects are extremely functional and multitasking systems. Think of a car that is stuffed with such embedded systems as dashboard devices, fuel injection and braking mechanisms, central locking and audio functionalities, transmission control system and many others. Their complexity is directly proportional to the level of security risks and vulnerability they are exposed to. It’s essential embedded development teams write code strictly in compliance with the international coding standards. Code mistakes can result in not only unforeseeable system behavior, disrupted project schedule and irritated users but set the stage for hackers to exploit the code breach.
Solution:
The secure code is quality code. Meeting fundamental code standards and practices will be helpful for both development and security teams. Consistent, coherently written, regularly reviewed code in combination with automated techniques and penetration testing is what can significantly prevent tricky and subtle warnings crawling the Internet.
Some of the most elaborate coding standards that meet security requirements include MISRA, CWE, and CERT.
3. The QA team can deal with security issues without extra help
The key problem of outsource development teams is that borders between roles and responsibilities are blurred and QA engineers are assigned to security tasks
Unfortunately, functional, performance, integration and other types of testing could not stand up to security vulnerabilities that can cause data breaches. In other words, QA team and in some cases developers mostly concentrate to make sure there's no gap in functionality and the application works as it is described in requirements. Security testing geared towards finding vulnerabilities that sometimes haven’t been known before. More often, developing and high-growth outsourcing companies do not yet have a separate security department and teams fail to embrace the whole scope of security measures.
Solution:
In the first place, it's essential to cultivate security mature mindset to dev teams. The key part is to adjust to the idea the system security is a part of system quality and it needs to be treated with the same prioritization level. Secondly, security requires a human approach and automated testing can’t hold a candle to it. More to that, quite often developers do not have the skills and knowledge of how to cope with security vulnerabilities. Hiring expertized security teams guarantees the reduction of risks that could lead to data loss or corruption.
4. One penetration testing session and you're all caught up
It's commonly known, disease prevention is cheaper than its treatment. That's why security consultants insist on regular pen test sessions.
The Internet network and software are highly dynamic fields and hackers are doing their best to be one step ahead of security guardians. Other reasons for a regular pen testing checkups include the usage of open-source resources or company presence in the media. Depending on the project field the outsourcing team works on they often face compliance requirements (e.g. ISO 27001 ISMS, PCI DSS, etc) that are essential to meet for a client. One more reason for a regular penetration testing is changes of the development environment that put the system in a vulnerable position and make it an easy target for intrusions.
Solution:
Depending on the outsourcing target company size the frequency can vary but annual testing is the least you can do.
Any company that process confidential information automatically becomes a potential target for rapidly developing cyber-attacks. Detecting system weaknesses via penetration testing is a cost-effective procedure that protects a company from financial losses and reputation tattering.
Additionally, at Dhound we've had experience in providing web and mobile penetration testing to satisfy compliance with SOC 2, PCI DSS, ISO 27001, HIPAA standards or prepare your system for the "Big Four" audit.
If you would like to receive a free consultation about Dhound pen-testing services or simply have no clue how to approach security and protect your apps, contact our security experts, willing to answer all of the questions
