Agile methodology

The Agile methodology is an iterative and incremental software development framework for managing product development. The basic agile events are:

• Iteration planning - Held at the start of each sprint to define the Iteration Backlog.
• Iteration grooming – The product owner works with the development team to elaborate user stories and design decisions.
• Iteration - A time-box of two or four weeks during which a “Done”, useable, and potentially releasable product increment is created.
• Daily Scrum - A daily meeting for the team to do a quick check on the status.
• Iteration Review – Event where team demonstrates the product and confirms that the outcome is as the expectation of product owner and customer.

Map secure development life cycle into Agile methodology

To successfully adopt security into agile methodology we tried to meet the following requirements:

• Security must be adaptive to agile software development methods.
• Security should offer concrete guidance and tools at all phases of development.
• The security approach must be simple; it should not hinder the development project.
• The most important SDLC activities – design modelling, security review, security testing, automatization, and static code analysis – have to be implemented in the appropriate agile phases.

Requirements - training

All development team members must attend unique security training focused on hands-on security flaws, writing secure code and doing security code reviews.

Design – STRIDE model – grooming, planning

With every new feature we ask the following questions:

• Is this feature susceptible to spoofing?
• Can this feature be tampered with?
• Can an attacker repudiate this action?
• Can an attacker get unauthorized access to information by attacking this feature?
• Can an attacker deny service to this feature or data flow?
• Can an attacker elevate their privilege by attacking this feature?

The following table shows security principle and example of measures related to each STRIDE fragment:

STRIDE model	Security principle	Measure
Spoofing	Authentication	Passwords, 2-factor authentication
Tampering	Integrity	Data/Input validation
Repudiation	Non-repudiation	Secure logging, Auditing
Information disclosure	Confidentiality	Encryption, Permissions
Denial of service	Availability	Filtering, Scalability
Elevation of privilege	Authorization	Permissions

Design security principles

Minimize attack surface

All code has a certain probability of containing flaws. If you have more code you have the higher probability that your application will have flaws. If you have more flaws then the attack surface of your application increases. In the design stage we focus on reducing the attack surface by:

• Minimizing the public access - Implementing appropriate access control mechanisms to protect Kontent.ai resources. 
• Reducing the amount of code - Removing unused code
• Following other principles – see next sections

Secure defaults

Our developers do base access decisions on permission rather than exclusion. This means that, by default, access is denied and the protection scheme identifies conditions under which access is permitted.

Example:

If new role is created, user have to select all capabilities it would be able to perform.

Use defense in depth

The principle of defense-in-depth is that layered security mechanisms increase security of the system as a whole. If an attack causes one security mechanism to fail, other mechanisms may still provide the necessary security to protect the system.

Example:

Protection against SQL injection may consist of several countermeasures:

• Proper input validation
• Implementing prepared statements
• Applying the least privilege level on DB server regarding the permissions
• Logging/monitoring DB transactions

Use the principle of least privilege

Simply limiting access to the minimal level that will allow normal functioning effectively mitigates the impact of any identity theft.

Example:

How can you implement the use of least privilege in order to secure your Cloud environment?

• For access management use RBAC.
• Assign access on the least possible scope - set of resources, resource groups or subscriptions.
• Regularly review permissions and accesses to the system if they are still needed.

A very similar approach applies to any system configuration etc.

Learn from mistake

Nobody is perfect and sometimes we make mistakes. When we find out a vulnerability in our code we immediately take the appropriate actions. As a part of investigation process we ask ourselves several questions:

• How did the security error occur?
• Is the same error replicated in other areas of the code?
• How could we have prevented this error from occurring?
• How do we make sure this kind of error does not happen in the future?

Step by step – the vulnerability is identified, the whole solution is analyzed if it doesn’t contain the same/similar issue and code improvements are implemented – e.g. writing new tests, creating a new custom script scanning the solution for similar issues or writing best practices.

Implementation - iteration cycle

In each iteration cycle when a new functionality is implemented our developers take advantage of knowledge they learned in the security training course. Implementation and code review cover not only top 10 vulnerabilities by OWASP but we also look for security issues in business logic.

Our security team automates all important activities to get faster feedback in case of security issue. Automated activities:

• REST API (backend) is regularly scanned using the automated web vulnerability scanner on a daily basis.
• When new public or internal endpoint is created our custom tool notifies team about the changes. 

Security team manually reviews all new endpoints to make sure the code has been properly reviewed by developers and does not contain any security issue.

Verification – review

The final security review helps assure that all relevant security aspects of the new functionality are considered. When a new functionality (usually divided into several subtasks during the implementation) is completed and ready to be published all outputs from security tools are audited to make sure no security issue has been found. If there are no issues identified by automated tool the security team did the final manual review. The following diagram shows the whole process.

There are two possible results of final security review. If no security issues were found the new functionality is ready to be published. Otherwise security team creates the appropriate bug, tracks the bug progress and when the bug is fixed the whole process is performed again.

Interested in more of Kontent.ai security? Check out our Security Policy.