Secure Process Adoption
Secure Process Adoption
In this post, we review the processes that development teams should follow during the SDLC in order to create high-quality, and highly-secure, software.
Join the DZone community and get the full member experience.Join For Free
Security processes need to be implemented in each and every layer of the application development lifecycle. The various layers which application development goes through are:
a) Requirement Analysis.
b) Design and Architecture.
c) Infrastructure Planning.
d) Coding and Development.
e) Review Process.
f) Testing (mandatory security testing).
g) All deliverables should be security compliant (any jars, DLLs, libraries) should be obfuscated.
h) Configuration Settings while deploying in various environments/Cloud.
i) Live environment.
Other aspects we should always consider as part of the security process is updating some important patch.
Software Patch: New code must always go through the security review process and testing. Any tool which is updated by a software patch update should not open any new security leaks. It's release notes should be properly read before installing.
Hardware update: Any significant plugin update or patch update needs to be monitored for any security leak.
a) Requirement Analysis: All important, project-related documents should always be an integral part of Information Security process. A best practice is to always have proper backups. Take that backup, install an antivirus on the backup servers and have a proper DR strategy. Versioning should be maintained in order to maintain the integrity of the documents and to maintain the Change records. Documents and folders should be password protected or be put in a secure repository which can only be accessed with the proper privileges.
b) Design and Architecture: This phase should include a Threat Modeling process, which can check for vulnerable areas and what course of action should be taken to mitigate threat agents. We should adhere to STRIDE and DREAD analysis. With this approach, we can forecast and have a defined strategy for incorporating security into the application's design and its architecture. Additionally, physical security and proper access privileages should be maintained.
For both the Requirement Analysis and the Capturing of the Design and Architecture documents phases, a proper auditing startegy should also be applied.
c) Infrastructure Planning: All hardware and other logistics should adhere to company standards and protocols. Infrastructure should be mapped as per the design and development. All procurements and licensing should be properly maintained in documents. Security policies should be applied to each physical and logical entity or resources and ACL policies should be adhered to. Managing network access should also be controlled with access privileges. Securing OS commands, applying DMZ, Firewalls, Securing ports, Network Hardening, and System logs and files should have strict ACL access and the credentials for which should be given to a bare minimum of individuals. Remote FTP or remote access should be carried out using strict access privileges.
d) Development: In the Development phase, first and foremost, a sense of Security awareness should be propagated within the team so that team is aware of security do's and don'ts. Some best practices are:
A proper Salted Password should be applied or a proper Password strategy should be decided upon.
Important IPs, PORTs, USERs, PASSWORDs must NOT be hardcoded.
The components of the page should only be displayed as required.
Any transfer of files/information should be done with the best encryption methodologies.
This should be also done for message transmission between different Interfaces.
Development IDEs like Eclipse have plugins like PMD, FindBugs, and Sonar applied to them, which can check for any security or improper coding so that developers are aware of any vulnerabilities and mitigate them.
Your build strategy should be applied in a CI/CD platform like Jenkins or Bamboo which will not create the jars/DLLs of files containing security leaks as identified by the above plugins.
Session Management should have a complete design document outlining how it is planned and executed since most of the dangerous vulnerabilities exist due to poor session handling.
The top 10 OWASP issues should be kept in mind while developing so that these vulnerabilities do not affect the code delivered.
A Standard Coding Checklist should be provided to the dev team from the security team/experts.
Running Sonar, FindBugs or any SAST tool should be made mandatory to provide both secure and high-quality code as well as deliverables.
A proper security framework or servlet filters which can stop unwanted or malicious requests from going over to the server should be used.
e) Review Process: Code reviews are not only an important part of the Agile development process but are also important from a security aspect. Reviews remain important even if we have incorporated SAST tools and adhered to good design principles. Manual reviews will also help in identifying some major code violations like hardcoding or passing sensitive information into logs. Tools like ZAP browser are quite handy to deduce any security vulnerability in the application and Xanitizer is also a good tool which can be used in the review process for Java-based software.
f) Testing: Testing is an important aspect and here we can make the call if the deliverables are good for deployment or not. We can perform proper black box testing and also have an ethical hacker test the application. Meanwhile, we should also use DAST tools like HP's WebInspect which can trigger the test and let us know if there are vulnerabilities in our application so that they can be mitigated before deployment. For majorly vulnerable areas, we can perform penetration testing.
g) All important deliverables should go through obfuscation so that they cannot be reverse engineered or hacked. All important 3rd party libraries/plugins should be checked for any security leakages, and, if any leaks are present, avoid using them. We can check them from an NVD database.
i) Configuration files kept in the cloud should have proper encryption in place and have some defined methodologies surrounding their use. Any recipe files like Docker or Chef should only be available to admins so that there is no security leakage or malicious software injections.
k) Live environments should be taken care of by known persons with proper ACL only. Proper DRs and load balancers should be maintained for live environments to be up 24/7. Any security patch or virus updates should be done with proper DRs and backups.
Opinions expressed by DZone contributors are their own.