Securing New Products at Clever
Clever Goals is a new product that tracks students’ educational software usage. It creates progress data, a new type of data for Clever. This sensitive data needs to be protected from unauthorized access, and users should feel in control over how it’s used. How does the Clever security team make sure that new products like Goals keep the bar high for student data protection?
Clever Goals progress data flow diagram, from our security review (component names omitted)
Early on, the Clever product team knew Goals would benefit from security and privacy design thinking. But entirely new products change direction frequently. No one wants to waste time on exhaustive security reviews for features they never ship. If the security team isn’t connected to other teams, security reviews can be a high-latency and low-context bottleneck. A collaborative security team can prevent risks even when they’re not in the room. This makes security a more flexible and lightweight part of the product iteration cycle.
Here are the key team relationships that drive secure product development at Clever. We recommend them to any organization that wants to develop secure new products rapidly.
Security and Infrastructure — From the Ground Up
When you design a product, you should make secure choices the default to reduce security risk over time. When Clever engineers create new services on our infrastructure platform, they don’t have to make many security-relevant decisions. They get minimal Docker images with an up-to-date language runtime. HTTP load balancers use strong TLS configurations. Secrets go in a purpose-built encrypted store. Our templates and deployment pipeline apply linting rules, encrypt data stores, and configure other secure defaults. Because security and software platforms both change so quickly, these functions in the organization should compare their roadmaps regularly. It’s much easier to configure security features early on than it is to change them in production.
Software companies often use a Platform as a Service (PaaS) like Heroku or Google App Engine for new products because the internal development platform is too cumbersome. Our infrastructure team wants to make creating and changing new services easy. But we want to do that using an interface we control. With security team collaboration, that interface can encode secure defaults, reducing the need for engineers to make decisions. Goals used our infrastructure platform from prototype to product, which suggests we’re keeping things easy for developers as we push towards more secure ways of building and deploying services.
Security and Product — Opening the Lines of Communication
Security teams want be involved early in the product development process. Product teams struggle with security team review and sign-off, especially when developing a new product that may change based on market feedback.
Communication between product teams and security teams keeps goals in harmony. At Clever, people can request a security review for their new project by sending a one-line message a Slack bot, which creates a ticket and instantiates a security review template, kicking off the security review process.
@securitybot creating a security review
The security team also reviews product team meeting notes and monitors code changes, determining if any new projects slip through the cracks.
While Goals took shape, the security team checked in on the progress, updating the threat model and providing new recommendations. We did a final security review before shipping to make sure the final product matched the security of our other Clever products.
Security and Policy — Understanding Privacy by Design
Clever has a responsibility to think about privacy when we build new products. We see privacy through two lenses; one is the federal, state, and contractual legal obligations we have, and the other is the idea that educational privacy is valuable in itself, to us and our customers.
Our security team worked with our legal team to ensure that Goals complies with existing laws and updated our policies to describe the new data flows we were supporting. With the guidance of our security team, the product team reviewed Fair Information Practice Principles to make sure administrators, teachers, and students had control over how their data was used. Clever wants to safely enable technology for K-12 students, and bridging the gap between teams help ensure these new data flows align with our values.
Security analysis is effective when it’s pervasive. Our team advocates for secure defaults while recognizing our infrastructure team’s efforts to drive developer productivity. We consider privacy as part of our requirements, and balance the needs of a fast-moving product team with our commitment to safeguarding district data. The challenges of new product development underline the importance of collaboration for a security team to reduce risk in an organization.
Originally published at Clever Engineering Blog.