Put down your cane and raise your hand (I'll wait) if you remember the "good ol' days" when developers were called engineers and "quality assurance" was a last-minute thing those same engineers did the night before a product release to ensure nothing lit on fire when the customer turned it on. Or, if you're not of that age yet, feel free to raise your hand if you remember the battles between developers and IT when trying to get a new tool up and running, or the times before iOS development when "user experience" was accomplished by drawing lines from one screen to another with some buttons placed in the right spot.
All of these shortcomings that we now see in our development process, over the past 25 years, have been resolved with the introduction of new disciplines into the industry: QA, DevOps and UX. Within these disciplines are many different roles, specializing more and more as technology continues to drive the demands of development companies further and further at breakneck speed.
I admit my surprise the first time, not long ago, when I referred to someone on our UX team as the person I assumed would be responsible for the creation of visual assets and I was told, with raised eyebrows, "Dude, I am not a visual [designer], I am the IA [information architect]!" I didn't realize our own team was composed of IAs, visuals, content managers and even front-end coders.
Imagine trying to get a quality product out the door today without the use of these specialties. Who would ensure the product functions as expected? Who would construct and maintain the environments for continuous development and delivery? Who would represent the needs and desires of the consumer to ensure adoption?
But if you ask, "How do you get a secure and compliant product out the door today?" the answer from most development teams will likely range from "I don't know" to "IT handles that, I think."
Security and compliance, once relegated to the backrooms of the IT department and the legal team, are now becoming front-and-center issues as more and more applications and services get hacked, breached, exposed and scattered across the front page of newspapers and tech websites almost every day. Not a week goes by when The Wall Street Journal is not reporting on yet another breach, and these span across every industry: government, healthcare, banking, retail, legal, lifestyle -- it doesn't matter who you are or what business you are in; chances are by now you have been affected by a vulnerability in a system.
And these vulnerabilities come from someone writing a piece of code, or creating a service, or adopting some open source software, who is simply unaware of (or does not care enough to research) the dangers associated with these bad practices. And with that comes the liability to companies in the form of lost business, of compensatory payments, of legal fees, of collapsing companies, of lost secrets and of regulatory punishment.
It's time for a formalization of a new discipline that can help prevent these mistakes from happening and that can help reduce the risk associated with common vulnerabilities, logic flaws, mistakes in architecture and lack of awareness with respect to security. I call this security engineering, for lack of a better (or cooler) name.
It's a discipline I practice daily in support of my company, and it covers a spectrum of services in the pursuit of producing better, safer, less risky and more secure products that adhere to the relevant regulations in a market. The security engineer's role engages across the life cycle of product: scoping security and compliance requirements, training development teams on best practices, consulting with the architects, modeling threats, analyzing code and product for vulnerabilities, assessing and monitoring risks, and much more.
This discipline is security in pursuit of designing, architecting, developing and deploying secure products; this is not your father's "security engineer," the one responsible for setting up firewalls and ensuring the VPN was running. While the latter is still an incredibly important role, this new role is about building secure products, rather than working with security products.
It requires deep knowledge of developer languages and practices, infrastructure architecture, usability design, legal liabilities and contractual language, regulatory standards, tooling, threat landscapes and hacker trends, supply chain management, and corporate governance. It begs for a passionate evangelist who can dig into dry and dusty regulatory documents, someone cynical enough to expect to be hacked at any time who can also be an enthusiastic and patient mentor, someone who can can dig deep into technical designs with fellow developers as well as clearly communicate the risks of product operations to executive and management teams.
As an industry, we need to continue to evolve our teams, our expertise and our skills to meet the demands of the markets. The markets are now demanding that their products be developed safely and securely, that their liability and risk of losing their customers' data be at a minimum, and that they are assured that the products they use are built to industry standards and meet or exceed the requirements of the regulations imposed.
Security engineering (or whatever we'd like to call it) is this next needed evolution, and it is needed now.
This article is published as part of the IDG Contributor Network. Want to Join?