Why is code security so difficult?

They have a mission, objective, a game plan and a set of trusted plays they run against enterprise networks. If you are building lists and checking boxes, you aren’t in the game – you are on the bench while the action is on the field of play … which happens to be your network, cloud assets, plants, partners, and supply chain. For instance, the attack surface is getting larger for the attackers to exploit and there are too many doors, windows and entry points. It is not a question of IF but WHEN and some of the latest include –

• Companies worry EU court ruling could disrupt global data transfers. The European Union’s highest court will decide Thursday whether a widely used tool for moving data from within the bloc to outside countries is legal. Companies have started looking for alternative methods to continue transferring personal information around the world ahead of the ruling.
• The European Court of Justice will determine whether a mechanism known as standard contractual clauses is enough to keep data private outside the bloc.
• SAP issues fix for vulnerability affecting thousands of customers. Enterprise software maker SAP SE said a patch released should fix a problem that could have let hackers take control of widely used applications. The Department of Homeland Security called the bug, known as Recon, a “critical vulnerability” and urged customers to apply SAP’s update immediately. It is estimated that 40,000 organizations are affected by Recon.
• New Jersey tech services firm hit by ransomware. Collabera, which provides technology services and staffing, detected a cyberattack that appeared to be ransomware. Employee data was compromised during the incident, according to an internal memo.

What is your playbook? Many security products are point solutions, meaning they solve one problem, sometimes well, sometimes not. Unfortunately, point solutions are often easy for adversaries to bypass. The challenge enterprises face is there are so many products to address so many threats at different points in enterprise architecture, each with its own requirements for management, and poor native integration capabilities.  One of many such vulnerabilities is “Injection.” SQL injection (SQLi) is a technique used to inject malicious code into existing SQL statements. Anything that accepts parameters as input can potentially be vulnerable to a code injection attack. SQL injection attacks can affect any application that uses a SQL database and handles data, including websites, desktops, and phone apps—with extremely serious consequences.  These injections make it possible for malicious users to bypass existing security controls and gain unauthorized access to obtain, modify, and extract data, including customer records, intellectual property, or personal information. Attackers can also use this technique to locate the credentials of administrators and gain complete control over affected websites, applications, and database servers. When managing a website, it’s important to stay on top of the most critical security risks and vulnerabilities.  Preventing code injection vulnerabilities really depends on the technology you are using on your website. For example, if you use WordPress, you could minimize code injection vulnerabilities by keeping it to a minimum of plugin and themes installed. If you have a tailored web application and a dedicated team of developers, you need to make sure to have security requirements your developers can follow when designing and writing software. This will allow them to keep thinking about security during the lifecycle of the project. We are as strong as our weakest link. Here are few actions we can take to prevent and detect injections:

• Separate data from the web application logic.
• Leverage SQL injection attack tool like Havij, SQLmap, or jSQL to identify vulnerable code.
• Apply patches and updates to the vulnerable code along with any other out-of-date components.
• Implement settings and/or restrictions to limit data exposure in case of successful injection attacks.
• The preferred option is to use a safe API, which avoids the use of the interpreter.
• Use positive or “whitelist” server-side input validation. This is not a complete defense as many applications require special characters, such as text areas or APIs for mobile applications.
• For any residual dynamic queries, escape special characters using the specific escape syntax for that interpreter.
• Use LIMIT and other SQL controls within queries to prevent mass disclosure of records in case of SQL injection.
• Consider setting up a web application firewall to filter malicious requests to your website. These can be particularly useful to provide protection against new vulnerabilities before patches are made available.