Thank You AppSec California. I Am Eager to See You Again!

By Arleena Faith

This January, I attended AppSec California for the first time. I woke up early and rode the Expo Line to Santa Monica. I took the Santa Monica stairs down to the sand and walked to the Annenberg Community Beach House. It was a nice venue, a nice walk, and a great experience.

I was excited about Gary McGraw’s opening speech and he did not disappoint me. Gary—the Vice President of Security Technology at Synopsys—taught me the three fundamental touch-points to scaling a Software Security Initiative (SSI) company-wide. Sound topic, for I was helping my team at work with an SSI project. Coincidently, I owned Gary’s book Software Security: Building Security In and had the opportunity to request his autograph by the end of his talk—which he politely signed—as well as taking pictures with me.

In his Scaling a Software Security Initiative: Lessons from the BSIMM presentation, Gary discussed why companies adopt the BSIMM model, which traces the evolution of different SSIs in many participant organizations and it provides fact-based visualizations from security trends among them. In other words: BSIMM reveals what is actively happening in the world of Software Security so that professionals developing an SSI have a foundation to build upon.

Gary described three activities from the Secure Software Development LifeCycle SSDL/SSDLC) that strengthen application security:

  • Architecture Analysis (AA)

  • Code Review (CR)

  • Security Testing (ST)

Gary McGraw and Arleena Faith

According to Gary, when these are enforced—sadly not always the case—they advance an SSI further.

Agreeing with Gary, Code Review should be mandatory across Software Development teams. Manual Static Analysis tools (like SecureAssist) can fulfill training and reporting goals simultaneously because of built-in secure coding guidance, in addition to other features (i.e. SecureAssist Enterprise Portal) for centralized reports and team progress tracking. However, automating SecureAssist is not feasible; this is where RIPS, FindBugs and more sophisticated, proprietary products (such as Synopsys’ Coverity) move beyond the basics.

Gary later suggested that Penetration Testing nowadays is a “commodity,” given the ever growing list of Cybersecurity vendors adopting it as one of the various services they offer. Eventually, third-party Penetration Testing drills scheduled as part of Security Testing are now more affordable than they were a decade ago, while other SSDL areas lack of comparable coverage.

Precisely, one of these critical areas lacking coverage due to a shortage of expertise is Architecture Analysis. Besides cooperation from all the developers, Architecture Analysis requires active knowledge of the existing software components and dependencies, their corresponding security vulnerabilities and flaws. Gary explained that many exercises fail since there is “no institutional knowledge or consistency” regarding what to do; not all the experts engage in every exercise and—for these and other reasons—an effective audit of the Security Architecture is not accomplished. Thus, building a Threat Model that accurately depicts the potential hazards a product faces in “the wild,” is unlikely. Gary recommended the Architecture Risk Analysis (ARA) from Synopsys and from the Institute of Electrical and Electronics Engineers (IEEE), the Avoiding The Top 10 Software Security Design Flaws guide. I surely took note and resolved digging deeper into Architecture Analysis.

A second, equally exciting presentation—indeed more exciting than what I imagined—was A Case for Integrity: JavaScript Apps Should Have it Too by Pedro Fortuna, the CTO of Jscrambler. Already familiar with several Javascript related projects at work, I added the event to my schedule. It took place on Wednesday (AppSec’s closing day) at the Garden Terrace Room.

Pedro Fortuna

Pedro’s main audience were coders and his style was extremely technical. Elaborating on the role of Javascript code integrity to neutralize browser attacks, he performed three “juicy” demos. Pedro also covered the principles of Threat Modeling and how to use a threat-based Traceability Matrix to visualize imminent risks. He reviewed a few integrity-based solutions readily available in the open-source community, though—unfortunately—still not widely adopted or not implemented correctly in most cases.

For instance, the Content Security Policy (CSP) is advantageous because it allows domain-based whitelisting. Currently a W3C working draft, it is helpful in averting Cross-Site Scripting (XSS) attacks but it needs a lot of maintenance and extensive configuration in order to work properly. Javascript “sandboxing” (another defensive technique) limits third party libraries, eliminates unsafe Javascript functions and supports policy implementation. Yet, it is vulnerable to injection and poisoning.

In Pedro’s view, Javascript code integrity starts by limiting client-side execution and integrating “defense-in-depth” methodologies that range from polymorphic Javascript, DOM Anti-Tampering to CSP and JS sandboxing. It entails a combination of efforts because end-user attacks, malicious browser extensions and Man-in-the-Browser (MitB) threats are highly ubiquitous and “here to stay.” Lastly, Pedro remarks, Javascript code integrity “It’s also about raising the bar.”

After leaving Pedro’s talk, I swiftly headed to the Marion Davies Guest House to watch Rod Cope’s presentation Continuous security: Bringing agility to the secure development lifecycle . I hoped to gain insight into pipeline-based security strategies, considering that I wanted to automate Security Testing within my team’s Continuous Integration (CI) environment at work. So, during the Q&A session I asked Rod and the guests for their recommendations—based on my intentions. They validated what I knew from individual research and previous experimentation: that trying the OWASP’s Zed Attack Proxy (ZAP) would my best choice. ZAP is free, open-source, and neatly versatile.

Today, looking back at AppSec California 2017, I feel grateful for what I learned there. I learned the three key touchpoints to scale an SSI from Gary McGraw, I learned how to protect the integrity of the Javascript code from Pedro Fortuna; I learned that sometimes “free” and open-source tools (like ZAP) are worth the time invested. More importantly, I reconnected with old friends and the Cybersecurity world—which is booming.

AppSec California, I am so eager to “see” you again!

About Arleena Faith

Arleena Faith studies Computer Science at the Harvard University Extension School, Harvard University, Cambridge, Massachusetts. Twice NASA intern and graduate from the NASA Community College Aerospace Scholar (NCCAS) workshop (Fall 2014), Arleena is interested in a diversity of Technology topics that range from CyberSecurity to Data Science. She focuses on Software Security since 2010, when she started her cyber-journey as a Junior Web Developer for a small company in Manhattan Beach, California.

More About Arleena

Watch ITSPTV Videos from AppSec California