Security for Modern Engineering Information Security & Risk Management
Download 132.18 Kb.
|
- Navigate this page:
- 5.2.1Static security analysis
- 5.2.1.3Transparent security
- 5.2.1.5Security education
- 5.2.2Dynamic security analysis
- 5.2.2.3Security education
- 5.2.3.2Plugging the gap for SOC
- 5.2.3.3Legacy applications
- 5.2.3.4Compensatory control
5.2AutomationTo enable teams for CI/CD and continuous assurance for security, automation must be a focal point in the solution. In support of this, our focus is to develop low-friction security services. We have identified the following three classes of services as key building blocks for our solution to deploy and maintain: 
Figure Three classes of Security Services 5.2.1Static security analysisStatic security analysis discovers security issues by scanning the code against a set of rules. It is one of the most valued activities in any mature SDL process. When static analysis is run in an Integrated Development Environment (IDE), engineers are exposed to potential security issues while they are coding the application. This instant feedback to engineers makes static analysis highly effective. The following foundational security principles (that static analysis promotes) are why we have focused so much on this security service capability: 5.2.1.1Code hygieneKnown security issues in the applications should not be present in the code we write and deploy. Granted, this is easier said than done, but this is our aspiration. Engineers are accountable to ensure code hygiene is addressed, and by leveraging static analysis they can do this effectively and efficiently. This is not to say that static analysis tools are perfect or that they are guaranteed to catch all issues. However, having a clean scan that reports zero issues – from a static analysis tool that addresses all known true positives – is what we consider basic hygiene. 5.2.1.2Code coverageManual line-by-line security assessment is a tiring activity (the human eye must examine lines of code for days), and it is also time-consuming and expensive. Additionally, manual inspection can vary greatly based on the experience and knowledge of the security analyst who looks at the code, which affects the consistency of the code reviews. Static analysis tooling, however, is consistent in terms of their rules and can cover millions of lines of code in a short period of time. This type of security service can provide the scale and code coverage that we needed. In fact, combining static analysis with human code review is one of the best ways to ensure all aspects of the application have been vetted. By leaving the common and tactical issues to the automated tool, we found that our most experienced security SMEs can focus their time on other important aspects such as design issues and business logic issues in higher-risk applications. 5.2.1.3Transparent securityWe have found that static analysis is most effective when it is integrated into the build process for the application. This makes the security control a part of the engineering process and makes it transparent to the end user. 5.2.1.4Moving security upstreamThe traditional security model verified code security after a piece of software was code complete, which is costly to fix. Static analysis allows us to move the code verification into the engineers’ IDEs so that security issues can be caught closer to the time code is written instead of waiting for the security team to catch all issues after the application is code complete. 5.2.1.5Security educationAs engineers get used to running static analysis for their day-to-day code development, they are exposed to security concepts and rules as they triage and learn from regular scan results. This helps to raise the security awareness within the engineering teams. 5.2.2Dynamic security analysisDynamic security analysis examines how code runs during the execution of a program. By reviewing how the code responds to and interacts with other system components, a dynamic security analysis tool can uncover security issues within the runtime. Dynamic security analysis discovers security issues by mimicking an attacker’s behavior on the actual application. We believe this service complements static analysis, and a combination of the two yields the best results in terms of completeness The following are security principles that dynamic analysis addresses and reasons why we think it is an essential part of the overall security automation strategy: 5.2.2.1HygieneDynamic security analysis helps engineers to test an application during runtime. As they test their application workflow, dynamic security analysis is another tool or service in their arsenal to leverage and verify that the application has fixed security defects that only surface when you run the application. 5.2.2.2CoverageDynamic security analysis can uncover different types of issues that may be non-discoverable to static analysis or can help validate issues discovered during static analysis. For example, the impact of environment and server-level configuration issues are easier to detect by running dynamic security scans. Potential information leaks that can occur as a result of interaction with the application can also be easier to discover through dynamic analysis versus static analysis. These issues can have severe impact and may be overlooked without effective dynamic scanning. 5.2.2.3Security educationSimilar to static analysis, dynamic security analysis also helps to raise security awareness within the engineering teams. 5.2.3Runtime detection and preventionA significant focus of the SDL is on proactive security controls and processes during development to ensure that the LOB applications we develop are secure from the ground up. There is a growing need to protect applications in a production environment as the threat landscape continues to evolve. Relying on static and dynamic analysis alone may not be sufficient. Code deployed to production may have gone through the SDL and static and dynamic analysis. However, due to “operational drifts” (where, for example, configurations of a runtime environment are altered), bug fixes, evolving threat landscape, and the fact that agile teams are always evolving code, there must be another layer of protection in a production environment. Runtime detection and protection for application – a technology that we think is still maturing in the industry – provides continuous assurance during application runtime. This is a nascent space, but it is a must-have service capability for the future and will become a crucial part of the overall application security strategy. We have identified the following risk areas that will benefit from a runtime detection service:
5.2.3.1DevOps and cloudEngineering teams continue to move toward a DevOps model, and also towards the cloud. This further shortens the end-to-end time to market (TTM) for a solution. It’s important that engineers use a detection service that hooks into the runtime and provides continuous security assurance and telemetry. This monitoring data enables the engineering teams and security teams to identify potential bad actors on the application layer. We believe this is a crucial component of securing the Ops in DevOps for modern engineers. 5.2.3.2Plugging the gap for SOCCurrently, Security Operations Center (SOC) for most organizations have visibility into host, network, and the end points from a monitoring standpoint. If an attack occurs on the application layer, very little is detected. A view from just the network is not enough anymore. 5.2.3.3Legacy applicationsRuntime detection can be an incredibly powerful tool to protect legacy applications which may no longer have any engineering support and are “sunset” applications. Such applications tend to use older technology stack which were less secure and easy targets for attacks. There could be cases where some applications are so old that they might not have gone through any software assurance processes whatsoever. 5.2.3.4Compensatory controlDue to time and resource constraints that agile teams face, even when application vulnerabilities are known, changing code to address new and existing threats could take time – often weeks or months – especially under non-agile methodologies. In such cases, applications that have known security issues may choose to implement runtime detection as a compensatory control for the time they need to fix the issues and beyond. Directory: download download -> Performance Tuning Guidelines for Windows Server 2008 May 20, 2009 Abstract download -> Northern England’s set-jetting locations download -> Bbc archives: Beyond the programme download download -> Occupational health and safety download -> Dynatest 3031 lwd light Weight Deflectometer download -> Forth coming competitive exams download -> English Olympiad Tasks: 10 th form Аудіювання, 10 клас. Текст download -> Brush High School Morning Announcements Friday, September 05, 2014 all school download -> Year 9 The Arts — Music download -> Years 7 and 8 standard elaborations — Australian Curriculum: Music draft Download 132.18 Kb. Share with your friends:
|