Secure Development Lifecycle Foundation

Security isn’t a feature. It’s a core principle that supports Milestone’s development process.

In this section, the fundamental secure requirements are described. They ensure that every product, tool, or service Milestone releases is shielded as best possible against potential threats and vulnerabilities.

The secure requirements cover essential procedures and criteria such as threat modeling, secure coding practices, and vulnerability tests and assessments. Each requirement has been carefully crafted to bolster the defense of Milestone’s products, tools, and services to protect both our customers and their users against cybersecurity threats as best possible.

Secure by Design and Secure Architecture

“Secure by Design” and “Secure Architecture” are closely related concepts in the field of cybersecurity and software development. They both emphasize the proactive incorporation of security principles into the design and development processes to create robust, resilient, and less vulnerable software products.

Secure by Design
Secure by design is a holistic approach to software development where security considerations are integrated into the entire software development lifecycle, from the initial design phase to deployment and maintenance. It places a strong emphasis on foundational security principles, such as the principle of least privilege, input validation, and secure coding practices.

The primary goal of secure by design is to address security at the earliest stages of development to prevent security vulnerabilities and weaknesses from being introduced in the first place.

Secure Architecture
Secure architecture is a part of the broader secure by design philosophy. It focuses on designing the overall structure and components of a system to be inherently secure, considering the system’s intended functions and potential security risks.

Specifically, secure architecture refers to the structural design of a system, software application or service and the network communication between system components. A secure architecture encompasses the design decisions that ensure data confidentiality, integrity, and availability, in addition to access control, secure communication, and other security-related aspects.

The relation between Secure Architecture and Secure by Design
The relation between secure architecture and secure by design lies in their shared objective of building secure and resilient systems from the ground up. In summary, secure architecture is a fundamental component of the broader secure by design approach. It involves designing the structural and architectural aspects of a system with security in mind, aligning with the principles and philosophy of Secure by Design to create robust and resilient software products.

Milestone will, during the design and development of Milestone’s products, tools and services, adhere to the concepts of Secure Architecture and Secure by Design as described here.

Secure by default

Milestone implements our software according to the secure by default principle, which is a principle in software development that aims to design and implement software systems with the highest level of security from the outset. This means that when a software product or system is deployed, it is by default configured to provide the strongest possible protection achievable without user configuration, minimizing potential security risks.

Secure by default covers the following areas, which Milestone will ensure to adhere to.

Default settings
Milestone’s software is developed to provide secure default settings to ensure our software offer the best protection against common security threats.

Least privilege
Milestone’s software is developed to adhere to the principle of least privilege.
This specifically means that software components interacting with other components of the Milestone products, are implemented with only the privileges necessary to perform the component’s intended tasks in the overall product.

This principle of least privilege also applies to user management, where, by default, new “standalone” users or roles containing multiple users, have no permissions until deliberately assigned permissions by the administrator of the software or system.

Authentication and authorization
Milestone’s software is developed to always provide strong authentication mechanisms that is enforced to access the software or system. Additionally, Milestone’s software will always provide authorization functionality to ensure users and integrated components or systems only can access resources they specifically have been granted access to.

Secure communication and encryption
Milestone’s software is, by default, developed to provide or use secure encryption for data at rest and during transmission. For functions where user configuration is needed to enable encryption, Milestone’s software is developed to request the user to perform the required configuration, or alternatively choose to disable encryption.

Explicit change consent
Milestone’s software is designed to not make any changes to the host computer’s operating system or it’s security settings that might reduce the security without detailed explanation to the user and the end-user’s explicit consent.

Optional functionality off by default
Milestone’s software is designed to reduce the cybersecurity attack surface and to reduce personal information exposure. This is done by having features, functions, services, or use of external services that are not critical for the fundamental functionality of the software, disabled by default.

Customers can then enable this functionality when needed. In cases where it is deemed that the user must be informed of the potential consequences of using the functionality, the user is informed about this, so the choice to enable it is an informed decision.

Fail securely
Milestone’s software is designed to follow the “fail securely” principle. One example of this principle is user authorization for accessing a resource. Only in the case where all parts involved in validating the user’s access permissions works and passes checks is the user provided access to the resource. In case a component fails, so access permissions cannot be checked or a security token cannot be renewed, access is denied.

Open design
Milestone’s software is designed to follow the “open design” security principle. This principle dictates that security may not rely on secrecy of the implementation. Instead, with “open design” the implementation, protocols, security measures and so on are publicly documented and can be examined and reviewed by anyone without this compromising the security and safeguards of the software.

Threat modeling

Threat modeling is a systematic approach used in software development to identify, evaluate, and mitigate potential security threats and vulnerabilities. It involves defining the security requirements, analyzing the software system’s design and architecture, identifying how attackers might exploit weaknesses and compromise its security and then mitigate the threats and validate that they have been mitigated.

Threat modeling is not a one-time activity, but an iterative process that continuously is performed when new functionality is implemented, or major changes are made.

By performing continuous threat modeling, development teams can effectively identify potential security issues early on, leading to a more secure and robust software product. Additionally, integrating threat modeling into the development process ensures that security is not an afterthought but a fundamental consideration throughout the entire software development lifecycle.

Threat assessment

As described in the Threat Modeling process, Milestone’s development teams will perform threat assessments at various stages throughout the software development lifecycle, to ensure the security of the developed components, features, or changes made.

Initial design and planning (Define):
Threat assessment activities are initiated during the initial requirements definition, design, and planning phase of the software development process. By incorporating threat assessment and security considerations early on, it is easier to identify potential risks and security requirements, leading to the development of a secure design.

Pre-development (Diagram):
Before the development phase begins, a threat assessment must be conducted to review the proposed architecture, technologies used, and security controls that are to be implemented. This assessment helps identify any major vulnerabilities or design flaws that need to be addressed before development starts.

Development (Identify and Mitigate):
Throughout the development process, Milestone’s development teams conduct regular threat assessments, typically in the form of code reviews, to identify potential security vulnerabilities in the code and address them.

Integration and Testing (Validate):
As components, features, or changes are integrated into the software product, a threat assessment is carried out to ensure the security of the integrated system. This threat assessment involves vulnerability scanning, penetration testing, and other security testing techniques to identify vulnerabilities and weaknesses in the system.

Repeated threat assessment cycle

Prior to Release:
Before releasing Milestone software to customers, a final threat assessment is conducted to verify that all identified vulnerabilities have been addressed and that the software meets the required security standards. This assessment may involve additional penetration testing, vulnerability scanning, or security audits.

Ongoing Maintenance and Updates:
Threat assessments are not limited to the development and deployment phases. Regular threat assessments are conducted during maintenance and update cycles of the Milestone software. This ensures that any new vulnerabilities that may have been introduced through updates or changes are identified and mitigated promptly.

Periodic and Regulatory Assessments:
In extension to the threat assessments performed during the development phases, Milestone conducts periodic threat assessments to ensure and maintain the security of the software product over time – even when nothing has been changed.

The reason for this is that new threats might appear after the software initially was developed and threat assessed. This periodic threat assessment might include scheduled vulnerability scans, penetration testing, and compliance assessments to ensure adherence to current security standards and regulatory requirements.

Defense in depth

Defense in depth is a security principle where several layers of security safeguards and risk-mitigation countermeasures are implemented. With such security layering, if one defense layer fails, another layer is there to block an attack. This intentional redundancy creates greater security and can protect against a wider variety of attacks.

Milestone implements our software following the defense in depth principle, to ensure that our customers can implement multiple security layers to protect their Milestone installation.

The list below shows a non-exhaustive list that exemplifies this principle applied in Milestone’s software:

Support for standard IT- and network-security measures, such as VLAN, VPN, firewalls, virus scanners and more
Encryption of data in transit and at rest
Support for various user authentication methods, including external identity providers (IDPs) offering multi-factor authentication and other security functionality
Detailed permission control and enforcement
Role separation between IT administration and security administration and operation.