Manage Identity and Access in Azure AD – Part 1

App Lifecycle Management Security

For the Application Lifecycle Management security perspective, there are a couple of best practices and steps defined by Microsoft in the Microsoft Security Development Lifecycle, which should be considered. Best part is that it has security and privacy considerations for all phases of the development lifecycle. To be true, the Microsoft Development Lifecycle is also used internally by Microsoft for is product development as well, which not Microsoft has made available for everyone’s use. This really helps in building secure solutions that meets security recommendations, are highly secure, and helps in reducing the development costs as well. Lets discuss them one at a time now.

1. Educate Your Team – Provide training to your team so that everyone in the team understands the security basics, define proper security policies and ensure that the security policies are followed.
2. Define Security Requirements – Which is a must when designing the solution itself. All the vulnerabilities must be thought through and the security requirements must be outlined properly that depends on the internal standards, legal and industrial requirements, and so on and so forth. This becomes the basis for defining the security policies. One very important thing is that the security requirements must be revisited frequently and accordingly the policies must be updated.
3. Define Metrics and Compliance Reporting – It’s prudent for the organization to define the minimum levels of security quality that can be accepted, This is needed early n the stage as it helps team to understand the risks associated with security issues that me arise, identify and fix security defects during development, and apply the defined standards throughout the entire project. This also required setting up the SLA as well and all other dependencies and metrics around it like – KPI’s, GPI’s, etc.
4. Threat Modeling – It is an extension to defining security requirements, where applying a structured approach to threat scenarios helps the team to more effectively identify security vulnerabilities and at lesser expense, determine risks from those threats, and then make security feature selections and establish appropriate mitigation. You can apply threat modeling at the component, application, or system level.
5. Establish Design Requirements – The designing of the application is done in advance, and so is the case with the security vulnerability identification, defining mitigation strategy, authentication and authorization, logging issues, etc. All these should be a part of your initial designing strategy.
6. Define and use the Cryptography Standards – Define the encryption strategy for all the components in your application. Apart from the application data at rest, we should also take care of the encryption od data in transit, and the hardware resources, and datacenters as well. Remember, we discussed about them in our previous slides.
7. Monitor and Manage Risks from Third Party Components – In developing todays high end solutions, it sometimes becomes necessary to use third party components. These components although are developed as per the industry standards, but still as an owner of your product, it’s your responsibility to monitor and manage the risks that might be imposed from the third party tools and components being used. It is very important to understand the impact that might be there with any security vulnerability in those components at large.
8. Use Approved Tools – This can be considered as an extension to the previous point that we just discussed. Analyze the security vulnerability and other risks with the third party tools and based on that take a decision to either approve or disapprove from being used in your project.
9. Security Testing – We then have the security testing, which can be divided into three parts –
   • Static Analysis Security Testing – A simple example of SAST is the security code review. This helps in ensuring that the security best practices are being followed. In general it is integrated into the commit pipeline for vulnerability identification.
   • Dynamic Analysis Security Testing – This type of verification is done at the run-time and is useful when all the components are integrated and are functioning together. One thing must be noticed that there is no one-size-fits-all, and this is the case with both SSAST and DAST.
   • Penetration Testing – This type of testing is done for applications/software, which have highly sensitive data and are very critical. An example could be a banks website. Penetration testing is done at the hacker level to identify and manage/mitigate the risk of failure and being hacked.
10. Define Standard Response Process – Finally, we should be defining a standard response process. It is a plan which is crucial for addressing in case there is a threat that has emerged. This should be according to your organizations defined threat response policy.

I guess it covers almost all the point and practices as defined in the Microsoft’s Security Development Lifecycle and they confirm to the industry best practices.

Pages: 1 2 3 4 5 6