Cyber security should be at the core of application development culture, not an afterthought

Summary

Reports of attackers penetrating highly-protected networks suggest that bad guys are winning. This note tells how we got here and suggests organizational and technical changes to improve security effectiveness.

Security shouldn’t be a separate discipline from software development or architecture. Security should be at the core of IT like balancing parentheses or committing transactions instead of a bunch of boxes to check if they can’t be avoided. We must weave security seamlessly into development and into enterprise architecture.

DBAs help with complex situations, but developers write their own SQL. The only way to get a dynamic app is for developers to code the database interactions.

Similarly, although the AppSec team can help with complex situations, the only way to get a secure app is for developers to write secure code. As with the long-ago switch to SQL, this culture change takes training and dedication.

Suggestions

· Treat security requirements in exactly the same way as business requirements so they can be prioritized, scheduled, coded, and factored into performance reviews along with business requirements. If teams use Jira, express security requirements as Jira stories so teams get story and velocity points for fixing them.

· Reward development teams for a penetration test where the ethical hackers can’t break in.

· Reward QA and test staff for finding security vulnerabilities on their own time. Offer a career path into pen testing if they’re good at it. They know the apps better than the DAST team and will find more.

· If we can’t move security to the left by letting developers and QA use pen testing tools, develop a cookbook of the many vulnerabilities that can be found with browser debuggers.

· Create standard configurations of popular frameworks such as Spring, Spring Boot, or .net with security built-in. We shouldn’t hire full stack developers who love to tweak the framework for resume polish.

· Configure a program to bypass the GUI to test RESTful interfaces using endpoint discovery to check every field for injection vulnerabilities along with cookie status and encryption level.

· Weave security into enterprise architecture instead of tacking security on after architecture is nearly done.

Background

I’ve been developing software since 1964 and spent the last 9 years in cyber security helping developers fix code so I could approve it for production deployment. I understand the world view which is shared by the security-aware segment of our IT community.

The 1960s ARPAnet inventors of what became the Internet ignored security because so few computers were involved. No one imagined that packet-switching would connect millions of computers into one world-wide web and that hackers could steal American money from North Korea.

The Internet evolved after Senator Al Gore sponsored 1983 and 1991 laws to consolidate government networks and open them to private investment. The “information superhighway” has accumulated enough poorly-patched potholes that it’s time to re-pave.

What Went Wrong

ARPAnet wasn’t designed for what the Internet became and we didn’t re-write basic infrastructure such as TCP/IP, DNS code, routers, or operating systems when attacks became common. Without a secure foundation, breaches result in an endless series of Band-Aid patches to web sites, mail utilities, calendars, and other parts of the IT universe.

The Band-Aid approach is mirrored in organization charts. Enterprise architecture teams plan hardware and software growth to meet future needs for capacity, reliability, and speed. Regulators demanded that separate security architecture teams focus on keeping bad guys out. Organizational separation defers security considerations until near the end of the architecture process.

A large organization has thousands of applications. Each year without a breach is thousands of breach-free app-years. Developers believe they’re more likely to be struck by lightning than to have their data stolen.

Application security groups are non-developer compliance enforcers who force developers to check security boxes without considering their scheduling commitments. Every picosecond developers spend on security costs the team money at the next annual review by reducing the amount of money-making code they deliver. Milestones missed when effort is diverted to security harm the team’s reputation. It makes career sense for developers to evade security whenever possible and code for revenue.

Organizational Tweaks

What if we made security worthwhile by offering dev teams bonuses for vulnerability-free pen tests?

Tracking vulnerabilities via the bug reporting system costs less than managing pen test issues via the compliance process. What if we offered QA and test teams bonuses for finding security vulnerabilities on their own time with a career path into pen testing if they become good at it?

Security architects come late to the party when they review the enterprise team’s plans. Security should be woven into architecture from the beginning by merging the teams.

Similarly, developers should give the same professional reverence to security as to business requirements. What if we put security user stories in the same sprint backlog as business stories so developers get story points and velocity credit for security? Developers would see how business requirements and security work together to generate revenue and security stories would count toward performance reviews.

Enhancing Development Culture — it takes a Village

Nobody can write a dynamic web application without understanding HTTP requests, HTTP responses, and data storage: SQL, noSQL, flat files, Cassandra, whatever. Useful apps implement business logic specified by the project sponsor. Secure apps need cookie security, response headers, and the OWASP top 10. Merging security into the existing SDLC requires an organizational and cultural change; it’s not a technical challenge.

Fixing vulnerabilities after the fact instead of during development brings the patch paradigm down to the application level whenever the application lets users do things they shouldn’t be able to do. The most common patch mistake is to block a useful feature while blocking the vulnerability. Making sure security doesn’t block too much requires a lot of testing. If the fix had been built in from the beginning, the normal test cycle would have made sure that all features were available after attacks were blocked.

Why should each development team have to fix well-known vulnerabilities? XSS and SQL injection are a decade old, for example. We should task a standards organization to release a secure version of a popular framework such as Spring or Spring Boot. Common security mitigations would be built-in without developers having to configure them.

Standardized frameworks would let organizations stop hiring the wrong people. Recruiters seek “full-stack developers” who love to tweak frameworks and drag in every Shiny New Object to polish their resumes. Having a standard RESTful configuration means we fund business logic to implement services customers pay for as opposed to paying for stack tweaks that make it harder to rotate staff between app teams.

As RESTful applications become common, we should extend an open-source penetration tool such as zap to use endpoint discovery to attack each parameter for XSS, CSRF, SQL injection, and whatever other attacks can be mounted without detailed application knowledge. This should run in the CI/CD pipeline and keep vulnerabilities from getting into the QA environment.

Organizations talk of “moving security to the left” in the SDLC but react in horror at the thought of developers being given penetration tools. Why not develop a list of vulnerabilities which can be found using browser debuggers to move some security left without triggering turf wars?

These organizational and procedural changes will improve security in the current Internet ecosystem. As a background task, we must rewrite many of the underlying mechanisms to make them inherently secure.

👋 Join us today !!

️Follow us on LinkedIn, Twitter, Facebook, and Instagram