Companies operating in the financial services industry today must comply with many complex regulatory standards. This makes perfect sense given that the assets and information managed by these companies are valuable and sensitive, and therefore are targeted by advanced cyber attackers. ..

The large amount of personal information (PII) processed by these organizations, which is subject to many industry standards and general data protection regulations, further complicates these challenges. Some regulations, such as PCI-DSS, are self-explanatory, while others are more common, stating that personal information simply needs to be protected from attacks. However, to comply with key regulatory standards, organizations need visibility into software risks, vulnerabilities, and data flows. You also need to have a system and plan to fix it.

Financial services organizations have always been strong in adopting application security testing tools, but there is much more they can do to accelerate and sustain their efforts.

So what specific steps can companies in this field take to ensure the security of the software they create for the remainder of 2021? And how does that help in the long run?

Risk ranking application

From a business risk perspective, not all applications are created the same. The first step in mitigating risk is therefore to quantify the inherent risks associated with each application. Organizations can achieve this by using risk-based methodologies to rank applications based on their potential damage to a company’s business goals following a successful attack.

For example, the security of an online banking application that allows customers to transfer funds, execute large transactions, and modify privileges is critical to a bank’s business goals. Violations of such applications can cause significant financial, regulatory and reputational damage. On the other hand, there may be internal applications that do not process sensitive information or that have a limited attack surface. From a business value perspective, these are less important and don’t warrant the same scrutiny from a safety perspective.

Ranking risks is a good place to start, allowing time and resource-limited security teams to apply the right resources to their riskiest applications to maximize operational efficiency. .. The result is an application inventory that includes the risk ranking for each application. You can then allocate resources based on the risk ranking of each business application.

Establish clear security requirements

To achieve true DevSecOps, teams must agree on “metrics” for appropriate security. This requires open and continuous communication and collaboration between development, security, and operations teams, as metrics vary by application type. For open source components, these requirements should include an understanding of each project, including level of community support, security history, and open source licensing requirements. For custom code and full applications, it is imperative to have an agreement that explicitly states when security testing will take place and under what conditions builds should be discontinued.

For example, an organization can (and should) prevent the deployment of an application if a “critical” vulnerability is identified. The automatic generation process of the application must be stopped if this condition is true.

Constantly identify vulnerabilities

Security should be built into all phases of software development for financial services organizations. Not only does this approach improve the security of your DevOps (i.e. DevSecOps) environment, previously discovered vulnerabilities are generally less complex and take less time to patch, resulting in faster time to market and costs. of development. Reduce.

Static Application Security Testing (SAST) solutions can be integrated into SDLC through the source code repository early in the code phase, when checking in new source code or adding it to the automated build process . You can use Software Configuration Analysis (SCA) in early releases to identify open source dependencies, map components to exposed vulnerabilities, and continue with the testing / QA phase. Integrated Application Security Testing (IAST) can be run during automated functional testing during the test / QA phase.

By integrating the above into the continuous integration (CI) orchestration, teams can automate the process and perform incremental scans of only changed code. In contrast, solutions that take hours to analyze a full version of an application do not fit well in a DevOps environment.

Enable developers to code securely from the start

It’s important that security teams take an active role in engaging and collaborating with their DevOps counterparts from the start. Education here is very important.

The security team in a financial services organization should train the DevOps team in specific attack methods and common hacking techniques, and provide the tools necessary to identify vulnerabilities while writing code. It should also serve as a soundboard throughout the process. By providing ongoing feedback and being able to respond to secure coding questions on demand, security teams can dramatically reduce the time it takes to remediate vulnerabilities, improve security, and deliver software. Can be made more predictable.

By establishing best practices and making Secure Coding Education (SCE) an ongoing process, security teams can make it easier for developers to code more securely from the start. Developers are more likely to take on relevant training, more easily retain lessons learned, and ultimately become a better security champion for their organization. It’s also helpful to specifically identify your development team’s security champion, to be the person you can rely on for security matters, and to be more connected to your security team compared to other teams. of development. I go.

Remembering application security is not a one-time task.

Open source components and frameworks have distinct advantages, such as lower development costs and faster time to market. However, to maintain strong security, it must be analyzed during the coding and construction stages. And that’s not all.

It’s important to keep an eye out for open source software for newly disclosed vulnerabilities throughout the SDLC. Some vulnerabilities such as ShellShock (CVE-2014-6271) It was discovered decades after the original vulnerability was introduced. Without visibility into both the version of the open source component and its location in the code base, it is very difficult to find and fix a vulnerability. Today, effective application security must be permanent.

Create a course for safe success

Today, malicious attackers are offering large amounts of PII used to steal personal information, but the impact of data breaches goes far beyond embarrassment for businesses. Attacks can damage a company’s reputation, shareholder value and, in some cases, leadership. And that’s before heavy fines, increased legislative inquiries and continued public mistrust.

The way financial services organizations create software today is radically different from what it was a decade ago, helping new development models deliver software faster than ever before.

Financial services organizations have a good track record to date, but the SDLC needs to be strengthened and maintained from the start. Combine SAST, SCA and IAST results to integrate different testing tools into a holistic view. In such a highly competitive market, offering something that has not been tested for security issues throughout the development process is no longer an option. The risk is simply too great.

We rely on both the software itself and its security to complete billions of transactions every day. Right from the start of SDLC, it’s time to ensure security integration. It only helps companies in this area to better manage, measure and manage risk, empower development teams, and ensure secure delivery of software at DevOps speeds.

Want to learn more about DevOps from the leaders in the space? Please see DevOps-as-a-Service SummitOn October 7, 2021, attendees will experience the benefits of building collaborations and partnerships in distribution.

label: development of, Financial affairs, Security, Software security



Source link

Leave a Reply

Your email address will not be published.