Secure design principles in the age of artificial intelligence

At Red Hat, we are committed to delivering trustworthy and robust products through a comprehensive security approach that encompasses many Secure Development Lifecycle (SDLC) activities. Our approach is grounded in the foundational principles of secure system design, which were first articulated 50 years ago in 1974 by Jerome Saltzer and Michael Schroeder in their seminal work: The Protection of Information in Computer Systems.

Try Red Hat Enterprise Linux AI

These principles, along with more recent advancements, such as those outlined in the CISA Secure by Design and SafeCode Fundamental Practices for Secure Software Development, remain crucial to building and maintaining increasingly secure software systems today. Additionally, we’ve also explored weakness and risk patterns and embarked on our Common Weakness Enumeration (CWE) journey to systematically address common vulnerabilities.

These concepts form the backbone of security in any IT system, and while they might be applied differently depending on the type of system, such as a cloud service vs. an on-prem solution, they are all important in designing more trustworthy architectures. In this article we take a look at some of the key principles we use during our SDLC activities.

Economy of mechanism

The key approach here is simplicity. In fact, the simpler the better. Complex systems tend to have more potential weaknesses. If a system’s design is simple and straightforward, it is easier to check for security issues. In our reviews, we look for places where complexity can be reduced to make the system more trustworthy and manageable.

In a web application, for example, using an industry-standard protocol, like OAuth 2.0 for authorization instead of building a custom solution minimizes complexity and, therefore, minimizes risk.

Secure by design, by default, in deployment

The concept of security by design, which includes the concept of security by default, is not new, as outlined in Exploring security by design and loosening guides. Security should be baked in from the start, not added on as an afterthought.

When we review a product or service, we try to make sure it’s secure by design, meaning that security features are built into the architecture. It should also be secure by default, meaning that default settings should always be the more secure option, and not be something users have to configure themselves. Finally, it should be secure in deployment, meaning that security measures remain in place throughout the software’s lifecycle.

For example, when deploying Red Hat Enterprise Linux (RHEL), the system is designed with security in mind, offering features like Security-Enhanced Linux (SELinux) to enforce access controls at the kernel level. By default, RHEL is configured with what Red Hat views as safe security settings, such as firewall rules and the least-privilege principle.

Open design

Open design is all about keeping things transparent. When systems are open for the community to review, their trustworthiness is increased. At Red Hat, open source is at the heart of everything we do, so this fits perfectly with our approach. It allows anyone to spot and fix security issues instead of relying on the old idea of “security through obscurity,” where the strategy is just to keep things hidden. Being open means better security through collaboration.

The Fedora Project is a perfect example of this. As the upstream source of RHEL, Fedora is developed openly with contributions from developers, testers and security experts worldwide. The entire design, roadmap and codebase are available for public scrutiny, so design weaknesses are more likely to be identified and addressed through peer review.

Complete mediation through access control

Every time someone accesses a resource in a system, that access should be verified and controlled. During our reviews, we look at how well access is controlled throughout the system. Every piece of data, every request, everything should be properly mediated to more effectively prevent unauthorized access.

In Red Hat OpenShift, every user must authenticate in some way to gain access. API requests with no or invalid authentication are authenticated as requests by the anonymous system user. Once authenticated, policy determines what the user is authorized to do.

Least privilege

At Red Hat, we follow the principle of least privilege to verify that every user, service and system component is granted only the access necessary to perform their specific tasks. Whether we’re reviewing a cloud service or an on-prem solution, we focus on tightening access controls to reduce the risk of insider threats or accidental misuse.

For instance, when setting up access control, “deny by default” should be the baseline. Systems should follow the principle of least privilege, with unnecessary services, daemons or user accounts disabled from the start. This approach helps keep security strong from development to deployment.

Least common mechanism

Sharing is not always caring; minimizing shared resources is essential to limiting security risks. Shared mechanisms can become single points of failure and increase the attack surface. We carefully review system designs to minimize unnecessary sharing between different users, services or processes. During our system design reviews, we verify that sensitive processes run in isolated environments, more effectively preventing any cross-contamination of resources.

Psychological acceptability

By prioritizing straightforward, user-friendly security controls, we make it easier for users to comply with security protocols, ultimately strengthening our overall security posture while enhancing the user experience. For example, consider our approach to authentication in OpenShift. We implement multifactor authentication (MFA) that is both trustworthy and user-friendly via Red Hat Single Sign-On (SSO). Instead of requiring users to remember multiple complex passwords or navigate a confusing setup process, our MFA solution is designed to be intuitive and easy to use.

Compromise recording

If something does go wrong and a breach occurs, it’s critical to know about it. Compromise recording makes sure that any security incidents are logged and tracked so they can be detected and responded to quickly. As part of our reviews, we confirm that systems have strong logging options and that monitoring can take place in order to catch suspicious activity.

Defense in depth

Rather than relying on a single line of defense, the defense in depth principle promotes layered security measures. We evaluate whether the architecture includes multiple, overlapping security controls at various levels of the system, so that even if one control is bypassed, others are in place to help mitigate the threat.

AI security

As artificial intelligence (AI) continues to evolve, Red Hat is adapting and extending these security principles to address the unique challenges posed by AI systems. As with traditional software, AI solutions must be designed with security at their core, particularly as they become more integrated into critical infrastructure, decision-making and automation. We are not only concerned with what could be considered an AI vulnerability, which we outlined in our newly published Red Hat security ratings for AI models, but also AI Safety to help protect against emerging risks.

Here are examples of key areas where we’re concentrating our efforts:

AI model integrity and authenticity

To prevent unauthorized tampering with AI models, Red Hat is focusing on model integrity and authenticity. We’re incorporating cryptographic signatures and version control systems to verify the authenticity of models, so any changes are tracked and legitimate.

For example, in RHEL AI, each AI model offered in the platform is assessed via cryptographic signatures that verify the integrity of the model before provided, so only authentic, untampered models are made available in the platform.

Bias mitigation

A key priority for Red Hat AI is addressing bias in models and training data. Through bias mitigation, we must conduct regular audits of training datasets to verify that they are representative and fair, implementing techniques to reduce biased predictions, and creating more equitable AI systems as outlined in our recent articles Security and safety of AI systems and Responsible and Explainable AI.

Conclusion

Red Hat is dedicated to maintaining our commitment to security by continuing to leveraging established principles of secure system design. By incorporating foundational guidelines, developed over 50 years ago and enhanced by modern practices, our products and services are not just more robust, but also more resilient against emerging threats.

Discover how RHEL AI and InstructLab can help you deploy customized, cutting-edge AI for your organization. Learn more today!