Verification

Architecture assessment

This is a guide for general security mechanisms such as authentication, authorization, user and rights management, secure communication, data protection, key management and log management.

• We have an agreed upon model of the overall software architecture
• We include components, interfaces, and integrations in the architecture model
• We verify the correct provision of general security mechanisms
• We log missing security controls as defects
• We consider different types of threats, including insider and data-related ones
• We use a formalized review method and structured validation

Secrets management

• All sensitive data is stored in key vault with the applications managed identity added to the access policy, accessed either via code or app configuration key vault reference
• We monitor and alert on expiring secrets
• Secrets should, where applicable be automatically rotated.

Attack surface hardening

TODO: Text about API exposures and mitigation

Guidelines regarding coding practices

• Follow the naming conventions for the project/language (files, folders, functions, etc).
• Look for the existing patterns and follow them.
• How are things named? Does every service function start with a “get-”?
• How are things structured? Are there specific folders to group similar code?
• Is the existing code organized in a certain way, or does it follow a particular design pattern (follow the code from API to the view for a similar feature)?
• Handle the unknown. What happens if the contract from the API is different and a property is missing? Where do I do validation? How do the existing features handle it?
• I see a problem with the way this is coded or structured. It can be done more efficiently.
• Tell the team about your idea before you start to refactor. It may be structured this way to handle a different scenario.
• The new way is better—great! We will update the style guides as a team and mark existing code as “deprecated” or with a comment to reference the new way.

You shall review your pull request (PR) and verify the above again.

• Have things changed since you wrote the first code, and does it need to be rewritten to follow the guidelines above?
• Has the contract from the API changed?
• Make it slow. In dev, everything runs on your machine. How will the user experience be if things are slowed down?
• Test and follow your code. Make it break. Has it been handled the way you wanted?

For cryptography see our guidelines documentation here

For input validation see our guidelines documentation here

Requirements and security testing

We conduct security tests to verify that the standard software security controls operate as expected. At a high level, this means testing the correct functioning of the confidentiality, integrity, and availability (CIA) controls of the data as well as the service. Our security tests should at least include testing for authentication, access control, input validation, encoding, and escaping data and encryption controls.

What to validate

We create misuse and abuse cases to misuse or exploit the weaknesses of controls in software features to attack an application. Use abuse-case models for an application to serve as fuel for identification of concrete security tests that directly or indirectly exploit the abuse scenarios.

Abuse of functionality, sometimes referred to as a business logic attack, depends on the design and implementation of application functions and features. An example is using a password reset flow to enumerate accounts. As part of business logic testing, identify the business rules that are important for the application and turn them into experiments to verify whether the application properly enforces the business rule.

You can use a generic security test suite that include security test cases to validate both positive and negative requirements for security controls such as:

• Identity
• Authentication & Access Control
• Input Validation & Encoding
• User and Session Management
• Error and Exception Handling
• Encryption
• Auditing and Logging

NOTE: Verify the correct execution of the security tests as early as possible.

How to validate

• We require dual command for production deploy pipelines
• We use recommended practices for source code control leveraging GitHub and related technologies where applicable

Load tests and fuzzing

Denial Of Service attacks typically result in application resource starvation or exhaustion. To determine if any resources can be used to create a denial of service, analyze each application resource to see how it can be exhausted. Prioritize actions unauthenticated user can do. Complement overall denial of service tests with security stress tests to perform actions or create conditions which cause delays, disruptions, or failures of the application under test.

Tools we use

For more information regarding tools we provide and use for security testing look Here