Figure 1: Security during Operate/Monitor phase – IoTAC Methodology

Operate

Just like in the Release and Deploy phase you should follow the principle of least privilege. Define a small group with the least access required to do the task. Use multi-factor authentication to prevent stolen passwords from being used against you.

Employ and follow a change governance framework. This will help you avoid shortcuts in deployment and recognize environment configuration drift. These benefits are the result of a combination of release automation and carefully designed policies and permissions for infrastructure changes.

Use an issue management tool to report and track bugs and change requests. Always execute a root-cause analysis and share the results with the development team. Make sure that the tool maintains a log of changes for each release.

Figure 2: Operate phase activities – IoTAC Methodology

Prepare and rehearse for disaster recovery. Implement a backup plan for each component with special attention towards secure storage. Estimate a mean time to recovery (MTTR) and record the actual time in any real recovery event.

Perform active monitoring, if an alert is received or some risk is indicated during monitoring, perform due diligence to alleviate or minimize the impact. Periodically run manual testing tools to evaluate system health.

Monitor

Ensuring application availability and security is a complex task that includes data collection, log analysis, automated self-defence, and alerting.

Monitoring and automatic notification are a must to ensure application and infrastructure health and therefore a smooth user experience. A monitoring tool needs to collect metrics about application performance and be able to present the data graphically to quickly ascertain its status. The tool should be determined during the plan and design phases and depends on your environment. Regardless of the exact tool chosen, you should be able to collect metrics about CPU utilization, RAM usage, requests, errors, response times, and incoming/outgoing network data volume over a certain period. Based on these metrics you can create automated alerts informing the operations team and, in cloud environments, trigger automatic actions to scale the infrastructure as needed. Make sure to include logging of user activities, errors, and hardware failures. Keep in mind these logs should not contain sensitive or personal information but should allow for queries to parse the data and present it for further analysis. When you receive an error, automatically create a notification, and consider creating a ticket as well.

The network is the main way attacks are made so we have to monitor them continuously and raise an alert when suspicious activity is recognized. Such as:

• Suddenly receive a large number of requests from a specific source
• Ports scan or other discovery tools are recognized
• Requests try to leverage well-known vulnerabilities
• Intrusion detection

In addition to network monitoring, we also need a security perimeter. You can accomplish this with a Web Application Firewall (WAF). The WAF can serve as a gateway to your application and helps recognize and prevent malicious requests or Distributed Denial of Service (DDOS) attacks.

Use Runtime Application Self-Protection as a concentric ring of security inside the WAF perimeter. Since RASP runs within your application on a server it is more aware of specific application design, possible vulnerabilities, and can detect and mitigate real-time attacks. It can notify security personnel, terminate a user’s session, send the attacker messages, and in extreme cases shut down the application to avoid the system from being compromised. RASP’s contextual awareness can also reduce the number of false-positive reports from less informed components.

Vulnerability scanning is an extension of the secure hardening verification approach discussed in the Release and Deploy methodology. While scanning on release is important, it is equally important to run the scan in production weekly, and vital to act if problems are discovered.

This scan should cover:

• OS, service, platform, framework, and component patch level and known vulnerabilities.
• Configuration settings of the environment to ensure that best practices are followed.
• Endpoint security check using common and newly discovered vulnerabilities.

The real key here is to make it a habitual task to scan, evaluate the results, and correct/improve the scan as needed.

The operate and monitor phase methodology may initially appear to be a static process but it is continuous and fluid. Using the proper tools and establishing secure habits you will see your application status, understand vulnerabilities, and repel threats. Cutting-edge security demands vigilance and the IoTAC’s security approach shows you how to meet this demand.

References

• Runtime application self-protection https://en.wikipedia.org/wiki/Runtime_application_self-protection
• Operating reliable systems  https://docs.microsoft.com/en-us/devops/operate/operating-reliable-systems-with-devops
• Security Content Automation Protocol https://csrc.nist.gov/projects/security-content-automation-protocol/

The post Operate & Monitor Phase Methodology appeared first on IoTAC.

Figure 1: Security during Release/Deploy phase – IoTAC Methodology

The release and deploy phase methodology is comprised of:

1. Release process automation
2. Environment management
3. Performance Testing
4. Dynamic Application Security Testing
5. Secure hardening verification approach

A key element to a secure release is automation. By using a CI/CD tool like GitLab you can remove error-prone manual steps and ensure consistency. Part of this automation includes checking the origin of the artifacts that your automated process creates. This allows you to sign and verify that the build has not been tampered with and you deploy only what you intended. Your application configuration also needs to be intensified. A common mistake is storing secrets in the source code. This is often overlooked in feature branches, but since the branch history is always available it poses a real threat. If you don’t use a dedicated secret management service, be sure to encrypt your secrets, and regardless of your means of storage only allow the application and a well-defined small group of people access to the settings.

An important piece of the automation pie is to include release pipeline integrity and execution. Again, limit pipeline access to a small well-defined group and ensure changes are monitored and logged. One way to accomplish this is by storing the pipeline definition in the source code repository and enforcing code reviews on branches used to deploy to Staging and Production. As for pipeline execution, it is best to have a manual approval step. This ensures nothing goes to Production without the knowledge and acceptance of key stakeholders. Be sure to log each deployment keeping track of a minimum of when it was deployed, what version, and who approved it.

Managing your environments with security in mind is crucial. Usually, this is broken down into Development, Staging, and Production to serve the needs of various stakeholders. For the development environment, no sensitive production data should be used to avoid accidental leaks. The staging environment should be configured as much like production as is possible including the same automated deployment process. Once the development is completed and all automated tests have run successfully, the application is deployed to the staging environment for further automated and manual testing. The production environment is for the end-users, but the Dev team will need secure access to investigate issues without compromising security. This can be done with monitored jump servers and applying data encryption so that crucial application data is not even available to the maintenance team. The environment setup and configuration must be documented and preferably automated. You can automate using Infrastructure as a Code which is an approach available, for Kubernetes or in Cloud environments.

Performance testing is another key element of application reliability, so it is recommended to perform a volume stress test that simulates requests and client actions. This requires test scenarios that generate a detailed report that can be evaluated and compared for negative impact. If changes are required the whole delivery pipeline should start over. The testing should validate the application is protected from Denial of service (DOS) attacks by either software or hardware components.

Dynamic Application Security Testing (DAST) needs to be implemented as well. DAST focuses on clearly defining a security baseline and having the deployed application employ vulnerability and patch-level scanning. The security baseline is defined for the specific component, including application binaries, application configuration, and infrastructure configuration. This will help to recognize any configuration drift between environments.

The secure hardening verification approach executes security validation in Staging to catch issues before being implemented in Production and it is also run periodically in Production to ensure safe operation. This includes vulnerability scanning of the infrastructure and application code, configuration management, penetration testing, Distributed Denial of Service (DDOS) validation, and following the principle of least privilege. Even with comprehensive automation, some things cannot be easily automated. To fill this gap Red teaming is recommended using a team of security professionals not related to the DEV team. They can perform penetration tests, test for SQL injection, and otherwise, try to infiltrate the system.

Secure release and deployment is not a simple endeavour, but following the release and deploy methodology as part of the IoTAC’s security approach is a surefire way to allow seamless communication with the utmost protection.

References

• Application and Release Security in GitLab https://docs.gitlab.com/ee/user/application_security/
• Delivering Quality Services https://docs.microsoft.com/en-us/devops/deliver/delivering-quality-services-with-devops
• Security in DevOps https://docs.microsoft.com/en-us/devops/operate/security-in-devops

The post Release & Deploy Phase Methodology appeared first on IoTAC.