Posts tagged "SPLC"

Evolving an Application Security Team

A centralized application security team, similar to ours here at Adobe, can be the key to driving the security vision of the company. It helps implement the Secure Product Lifecycle (SPLC) and provide security expertise within the organization.  To stay current and have impact within the organization, a security team also needs to be in the mode of continuous evolution and learning. At inception of such a team, impact is usually localized more simply to applications that the team reviews.  As the team matures, the team can start to influence the security posture across the whole organization. I lead the team of security researchers at Adobe. Our team’s charter is to provide security expertise to all application teams in the company.  At Adobe, we have seen our team mature over time. As we look back, we would like to share the various phases of evolution that we have gone through along the way.

Stage 1:  Dig Deeper

In the first stage, the team is in the phase of forming and acquires the required security skills through hiring and organic learning. The individuals on the team bring varied security expertise, experience, and a desired skillset to the team. During this stage, the team looks for applicability of security knowledge to the applications that the engineering teams develop.  The security team starts this by doing deep dives into the application architecture and understanding why the products are being created in the first place. Here the team understands the organization’s application portfolio, observes common design patterns, and then starts to build the bigger picture on how applications come together as a solution.   Sharing learnings within the team is key to accelerating to the next stage.

By reviewing applications individually, the security team starts to understand the “elephants in the room” better and is also able to prioritize based on risk profile. A security team will primarily witness this stage during inception. But, it could witness it again if it undergoes major course changes, takes on new areas such as an acquisition, or must take on a new technical direction.

Stage 2: Research

In the second stage, the security team is already able to perform security reviews for most applications, or at least a thematically related group of them, with relative ease.  The security team may then start to observe gaps in their security knowhow due to things such as changes in broader industry or company engineering practices or adoption of new technology stacks.

During this phase, the security team starts to invest time in researching any necessary security tradeoffs and relative security strength of newer technologies being explored or adopted by application engineering teams. This research and its practical application within the organization has the benefit of helping to establish security experts on a wider range of topics within the team.

This stage helps security teams stay ahead of the curve, grow security subject matter expertise, update any training materials, and helps them give more meaningful security advice to other engineering teams. For example, Adobe’s application security team was initially skilled in desktop security best practices. It evolved its skillset as the company launched products centered around the cloud and mobile platforms. This newly acquired skillset required further specializationwhen the company started exploring more “bleeding edge” cloud technologies such as containerization for building micro-services.

Stage 3: Security Impact

As security teams become efficient in reviewing solutions and can keep up with technological advances, they can then start looking at homogeneous security improvements across their entire organization.  This has the potential of a much broader impact on the organization. Therefore, this requires the security team to be appropriately scalable to match possible increasing demands upon it.

If a security team member wants to make this broader impact, the first step is identification of a problem that can be applied to a larger set of applications.  In other words, you must ask members of a security team to pick and own a particularly interesting security problem and try to solve it across a larger section of the company.

Within Adobe, we were able to identify a handful of key projects that fit the above criteria for our security team to tackle. Some examples include:

  1. Defining the Amazon Web Services (AWS) minimum security bar for the entire company
  2. Implementing appropriate transport layer security (TLS) configurations on Adobe domains
  3. Validating that product teams did not store secrets or credentials in their source code
  4. Forcing use of browser supported security flags (i.e. XSS-Protection, X-Frame-Options, etc.) to help protect web applications.

The scope of these solutions varied from just business critical applications to the entire company.

Some guidelines that we set within our own team to achieve this were as follows:

  1. The problem statement, like an elevator pitch, should be simple and easily understandable by all levels within the engineering teams – including senior management.
  2. The security researcher was free to define the scope and choose how the problem could be solved.
  3. The improvements made by engineering teams should be measurable in a repeatable way. This would allow for easier identification of any security regressions.
  4. Existing channels for reporting security backlog items to engineering teams must be utilized versus spinning up new processes.
  5. Though automation is generally viewed as a key to scalability for these types of solutions, the team also had flexibility to adopt any method deemed most appropriate. For example, a researcher could front-load code analysis and only provide precise security flaws uncovered to the application engineering team.  Similarly, a researcher could establish required “minimum bars” for application engineering teams helping to set new company security standards. The onus is then placed on the application engineering teams to achieve compliance against the new or updated standards.

For projects that required running tests repeatedly, we leveraged our Security Automation Framework. This helped automate tasks such as validation. For others, clear standards were established for application security teams. Once a defined confidence goal is reached within the security team about compliance against those standards, automated validation could be introduced.

Pivoting Around an Application versus a Problem

When applications undergo a penetration test, threat modeling, or a tool-based scan, teams must first address critical issues before resolving lower priority issues. Such an effort probes an application from many directions attempting to extract all known security issues.  In this case, the focus is on the application and its security issues are not known when the engagement starts.  Once problems are found, the application team owns fixing it.

On the other hand, if you choose to tackle one of the broader security problems for the organization, you test against a range of applications, mitigate it as quickly as possible for those applications, and make a goal to eventually eradicate the issue entirely from the organization.  Today, teams are often forced into reactively resolving such big problems as critical issues – often due to broader industry security vulnerabilities that affect multiple companies all at once.  Heartbleed and other similar named vulnerabilities are good examples of this.  The Adobe security team attempts to resolve as many known issues as possible proactively in an attempt to help lessen the organizational disruption when big industry-wide issues come along. This approach is our recipe for having a positive security impact across the organization.

It is worth noting that security teams will move in and out of the above stages and the stages will tend to repeat themselves over time.  For example, a new acquisition or a new platform might require deeper dives to understand.  Similarly, new technology trends will require investment in research.  Going after specific, broad security problems complements the deep dives and helps improve the security posture for the entire company.

We have found it very useful to have members of the security team take ownership of these “really big” security trends we see and help improve results across the company around it. These efforts are ongoing and we will share more insights in future blog posts.

Mohit Kalra
Sr. Manager, Secure Software Engineering

Pwn2Own 2017

The ZDI Pwn2Own contest celebrated its tenth anniversary this year. Working for Adobe over the past ten years, I have seen a lot of changes in the contest as both an observer and as a vendor triaging the reports.

People often focus on the high level of aspects of who got pwned, how many times, in how many seconds, etc. However, very little of the hyped information is relevant to the actual state of security for the targeted application. There are a lot of factors that determine whether a team chooses to target a platform outside of its relative difficulty.  These can include weighing how to maximize points, the time to prepare, personal skill sets, difficulty in customizing for the target environment, and overall team strategy. ZDI has to publish extremely detailed specs for the targeted environment because even minor device driver differences can kill some exploit chains.

For instance, some of the products that were new additions this year were harder for the teams to add to their target list in time for the competition. On the other hand, it was unsurprising that Tencent and Qihoo 360 both competed against Flash Player since they regularly contribute responsible disclosures to Adobe’s Flash Player and Reader teams. In fact, Tencent was listed in our January Flash Player bulletin and we credited two Flash Player CVEs to the Qihoo 360 Vulcan Team in our March Flash Player security bulletin that went out the day before the contest. On the Reader side, Tencent team members were responsible 19 CVEs in the January release. Therefore, both teams regularly contribute to Adobe’s product security regardless of Pwn2Own.

The vendors don’t make it easy for the competitors. For instance, since the contest occurs after Patch Tuesday, there is always the chance that their bugs will collide with the vendors patch release. For instance, Chrome released 36 patches in March, VMWare had two security updates in March, and Flash Player released seven patches in our March release. In addition, new mitigations sometimes coincide with the contest. Last year, Flash Player switched to Microsoft’s Low Fragmentation Heap and started zeroing memory on free in the release prior to the contest. As a result, one of the Pwn2Own teams from that year did not have time to adjust their attack. This year, Flash Player added more mitigations around heap and metadata isolation in the Patch Tuesday release.

Adobe doesn’t target the mitigations for the contest specifically. These occur as part of our Adobe Secure Product Lifecycle (SPLC) process that continually adds new mitigations. For instance, between Pwn2Own last year and Pwn2Own this year, we added zeroing memory on allocation, running Flash Player in a separate process on Edge, blocking Win32k system calls and font access in Chrome, adding memory protections based on the Microsoft MemProtect concept, and several similar mitigations that are too detailed to include in a simple list. Similarly, Mozilla has been working on instrumenting sandboxing for their browser over the last year. Therefore, this is a contest that does not get any easier as time goes on. If you want to try and sweep all the Pwn2Own categories, then you need a team to do it.

In fact, a lot has changed since 2008 when Flash Player was first hacked in a Pwn2Own contest. The list of mitigations that Flash Player currently has in place includes compiler flags such as GS, SEH, DEP, ASLR and CFG. We have added sandboxing techniques such as job controls, low integrity processes, and app containers for Firefox, Chrome, Safari, and Edge. There have been memory defenses added that include constant folding, constant blinding, random NOP insertion, heap isolation, object length checks, replacing custom heaps, and implementing MemProtect. In addition, the code has gone through rounds of Google fuzzing, Project Zero reviews, and countless contributions from the security community to help eliminate bugs in addition to our internal efforts.

While advanced teams such as Qihoo 360 and Tencent can keep up, that security hardening has hindered others who target Flash Player. For instance, ThreatPost recently wrote an article noting that Trustwave measured a 300% drop in exploit kit activity. While exploit kit activity can be influenced by several factors including law enforcement and market ROI, the CVEs noted in exploit kits are for older versions of Flash Player. As we add mitigations, they not only need new bugs but also new mitigation bypass strategies in order to keep their code working. In addition, ThreatPost noted a recent Qualys report measuring a 40% increase in Flash Player patch adoption which helps to limit the impact of those older bugs. Zero days also have been pushed towards targeting a more limited set of environments.

All of that said, nobody is resting on their laurels. Advanced persistent threats (APTs) will select technology targets based on their mission. If your software is deployed in the environment an APT is targeting, then they will do what is necessary to accomplish their mission. Similarly, in Pwn2Own, we see teams go to extraordinary lengths to accomplish their goals. For instance, Chaitin Security Research Lab chained together six different bugs in order to exploit Safari on MacOS.  Therefore, seeing these creative weaponization techniques inspires us to think of new ways that we can further improve our defenses against determined malicious attackers.

The ZDI team has done a tremendous job improving Pwn2Own each year and adding interesting new levels of gamification. It is amazing to watch how different teams rise to the occasion. Due to the increased difficulty added by vendors each year, even winning a single category becomes a bigger deal with each new year. Thanks to everyone who contributed to making Pwn2Own 2017 a great success.

Peleus Uhley
Principal Scientist

Join Members of our Security Team at AppSec Europe and Security of Things World

Our director of secure software engineering, Dave Lenoe, will be speaking at the upcoming Security of Things World conference in Berlin, Germany, June 27 – 28. In addition, two more members of our security team will also be speaking at the upcoming OWASP AppSec Europe conference in Rome, Italy, June 27 – July 1.

First up is Dave at Security of Things World. He will be speaking about how Adobe engages with the broader security community for both proactive and reactive assistance in finding and resolving vulnerabilities in our solutions. You can join him on Monday, June 27, at 2:30 p.m.

Next up will be Julia Knecht, security analyst for Adobe Marketing Cloud, at OWASP AppSec Europe to share lessons learned from developing and employing an effective Secure Product Lifecycle (SPLC) process for our Marketing Cloud solutions. This session will give you on-the-ground knowledge that may assist you in developing your own SAAS-ready SPLC that helps break down silos in your organization, making it more agile and effective at building secure solutions. Julia’s session will be on Thursday, June 30th, at 3:00 p.m.

Finally, Vaibhav Gupta, security researcher, will be leading a “lightning training” on the OWASP Zed Attack Proxy (ZAP) tool at OWASP AppSec Europe. ZAP is one of the world’s most popular free security tools and is actively maintained by hundreds of international volunteers. It helps you automatically find security vulnerabilities in your web applications while you are developing and testing them. This training is focused on helping you with ZAP automation to enable better integration of it into your DevOps environment. Vaibhav’s session will be on Friday, July 1st, at 10:20 a.m.

If you will be at either of these conferences next week, we hope you can join our team for their sessions and conversation after or in the hallways throughout the event.

Building a Team of Digital Marketing Security Champions

Two years ago, I joined the Digital Marketing Product Security Team and took on the responsibility of establishing and managing the Secure Product Lifecycle (SPLC) process for Digital Marketing Product Engineering. There are currently eight Digital Marketing Solutions with engineering teams located all over the world.  Many of these solutions came to Adobe by way of acquisition.  I work with differing stacks, languages, company cultures, and time zones.  I knew some of the engineers from having run our 3rd Party Penetration Testing program for three years – however, I was mostly starting the process from scratch. My main goal was to lower security overhead in the product development cycle and leverage existing processes.

I am very passionate about quickly making improved security an integrated part of our product development and leveraging as many existing processes and tools as possible.   In order to promote security knowledge throughout the large Digital Marketing engineering organization.  I created a human “botnet” of security champions. These champions come from positions all over the organization and coordinate with our security team to facilitate ongoing management and enforcement of our SPLC process.

Security, admittedly, has a bit of an “image problem” among development teams.  It is something that developers often think of as this big, scary set of tasks intended to make their jobs more difficult or less enjoyable.  We placed a big emphasis on changing this perception. The Digital Marketing Security team is focused on being a supportive, service organization – a far cry from the perception that we can be a terrible force of nature leaving engineers feeling like they’ve been hit by a truck or would like to be.  Rather than coming in with the metaphorical hammer, we thought, “can we get people to actually enjoy their interactions with our security team?  How can we make this incredibly important, but often dreaded, piece of software development an integral and easier to implement piece of the existing process?”

The first thing I did was to meet with the solution owners and program managers to learn about how these teams develop and deliver software for these SAAS offerings.  Adobe has an incredible program management network, and an existing Service Lifecycle program that I was able to leverage and adapt to help meet requirements of our Secure Product Lifecycle.  I worked with the program managers to figure out how we could best add SPLC steps to their development and release process. I also ensured we had a clear process for adding security requirements and checkpoints to the release process. I worked with solution engineering directors to identify Security Champions on their engineering teams who would work with me to continue to improve our approach to security for the solutions.

A Security Champion is: ‘An advocate of security and the Digital Marketing Security team’s point of contact for the solution.  The champion has a good understanding of the technology, an interest in ensuring better security for their offering, and a strong personal network in the engineering organization.’  Once this human “botnet” of Security Champions was established, the heavy lifting began.  I set key performance indicators (KPIs) for the different elements of the SPLC around security training, threat modeling, static/dynamic analysis and penetration testing. The very first KPI that we focus on, for the purpose of enabling the proper background for having security conversations with the engineers, is technical security training.  Adobe’s corporate secure software engineering team (known as “ASSET”) has created a fantastic training program that focuses on technical security topics and awards certifications in the form of white and green belts, similar to karate training. Each of the program managers have added this training to the new engineer onboarding steps and they and the security champions have helped to develop strong measurements for the other KPIs.

My Security Champions helped increase the pervasiveness of our “security culture” more than I could have imagined when first starting this program.  They are one of the driving forces in helping to further improve security across Adobe’s Digital Marketing solutions.  They have been an amazing force multiplier helping to prioritize security practices in their teams’ design process, roadmap development, and mindset.

About 6 months after kicking off the Security Champions program, Digital Marketing Engineering had grown their base of security knowledge to have over 95% of their engineers white and green belt certified.  We’d also increased the number of threat models, penetration tests, ongoing security projects, and automated security testing. Our metrics against these initiatives have continued to increase and improve. The teams are more proactively involving the Digital Marketing and corporate security teams in their design discussions helping to ensure better security implementations throughout the process.

Messages like this from the teams show it’s working and make it all worth it:

Picture1

We’re committed to building and maintaining the trust of our Digital Marketing customers by developing and providing them with the most secure software possible – solutions that help meet business demands and allow configurations to help meet their security and compliance needs.  The SPLC and Security Champions program have helped to broaden the security knowledge and awareness of the Digital Marketing engineering teams.  We will continue to raise that bar by continuing to iterate and improve on these programs.

Julia Knecht
Security Analyst, Digital Marketing

Security Collaboration at Adobe

At Adobe we recognize that our customers benefit when we take a collaborative approach to vulnerability disclosure.  We pride ourselves on the symbiotic relationship we’ve cultivated with the security community and continue to value the contributions that security researchers of all stripes make to hardening our software.

As a measure of the value we place in external code reviews and security testing, Adobe interfaces with the security community through a spectrum of engagement models, including (but not limited to):

  • Traditional third-party code reviews and pen-tests
  • Crowd-sourced pen-tests
  • Voluntary disclosures to our Product Security Incident Response Team (PSIRT)
  • Submissions to our web application disclosure program on HackerOne

Code reviews and pen-tests

Before Adobe introduces a major upgrade or new product, feature or online service offering, a code review and pen-test is often performed by an external security company.  These traditional third-party reviews provide a layer of assurance to complement our internal security assessments and static code analysis that are part of our Secure Product Lifecycle (SPLC).

Crowd-sourced pen-tests

To benefit from a larger pool of security researchers, Adobe also uses crowd-sourced pen-tests in tightly scoped, time-bound engagements involving an elite pool of pen-testers targeting a single service offering or web application.   This approach has helped supplement the traditional pen tests against our online services by increasing code coverage and testing techniques.

Disclosures to PSIRT

The Product Security Incident Response Team (PSIRT) is responsible for Adobe’s vulnerability disclosure program, and typically responds first to the security community’s submissions of vulnerabilities affecting an Adobe product, online service or web property.  In addition to its role as conduit with external researchers, PSIRT partners with both internal and external stakeholders to ensure vulnerabilities are handled in a manner that both minimizes risk to customers and encourages researchers to disclose in a coordinated fashion.

Disclosures via HackerOne

In March 2015, Adobe launched its web application vulnerability disclosure program on HackerOne.  This platform offers researchers the opportunity to build a reputation and learn from others in the community, while allowing vendors to streamline workflows and scale resources more effectively.

As new bug hunting and reporting platforms enable part-time hobbyists to become full-time freelance researchers, we look forward to continuing a constructive collaboration with an ever-widening pool of security experts.

 

Pieter Ockers
PSIRT Security Program Manager

Disha Agarwal
Product Security Manager

Applying the SANS Cybersecurity Engineering Graduate Certificate to Adobe’s Secure Product Lifecycle (part 1 of 2)

In the constantly changing world of product security it is critical for development teams to stay current on the current trends in cybersecurity. The Adobe Photoshop team evaluates additional training programs often to help complement Adobe’s ASSET Software Security Certification Program.  One of those is the SANS Cybersecurity Engineering Graduate Certificate Program.  This blog series discusses how we are leveraging the knowledge from this program to help improve product security for Adobe Photoshop.

The SANS Cybersecurity Engineering Graduate Certificate is a three course certificate that offers hand’s on practical security training – such as in the proper usage of static code analysis. A best practice of modern software development is to perform static code analysis early in the software development lifecycle before the code is released to quality engineering. On the Photoshop team we use static code analysis regularly in our continuous build environment. This analysis helps ensure that if there are any new defects introduced during development, they can be immediately fixed by the engineer who added them. This allows the quality engineering team to focus on automation, functional testing, usability testing and other aspects of overall quality instead of, for example, accidental NULL dereferences.

In addition to the course material and labs, graduate students are asked to write peer-reviewed research papers. I am primarily responsible for security of the Adobe Photoshop CC desktop application and I developed my research paper based upon my experiences. When the Heartbleed bug was disclosed in April 2014, I was curious to know why this type of bug wasn’t caught by static analysis tools. I chose to examine this question and how it applies to Photoshop.

The resulting paper, The Role of Static Analysis in Heartbleed, showed that Heartbleed wasn’t initially caught by static analysis tools. This is because one of the goals of static analysis is not to generate too many false positives that the engineers need to sift through. To solve this, we asked the vendor of one of the popular static analysis tools, Coverity, to add a new TAINTED_SCALAR checker which was general enough to not only detect Heartbleed, but also other potential byte-swap defects. Andy Chou’s blog post details how by looking at byte-swap operations specifically, and not by making the checker only specific to Heartbleed, other software development teams can benefit. This idea was proven correct when the Photoshop team applied the latest release of Coverity’s tools including our request to our codebase. We have identified and fixed a number of issues from this new TAINTED_SCALAR checker.

The value of additional training can only be fully realized if you can apply the knowledge to a set of problems that are found on the job. This is one of the advantages of the SANS program – the  practical application of applying this knowledge through a research paper makes the program more valuable to my work.

In part 2 of this blog series, I will examine how the NetWars platform was used to help the overall security profile of Adobe Photoshop.

Jeff Sass
Engineering Manager, Photoshop

An Industry Leader’s Contributions

In the security industry, we’re focused on the impact of offensive advancements and how to best adapt defensive strategies without much reflection on how our industry has evolved.  I wanted to take a moment to reflect on the history of our industry in the context of one individual’s contribution.

After many years in the software engineering and security business, Steve Lipner, Partner Director of Program Management, will retire from Microsoft this month.  Steve’s contributions to the security industry are many and far reaching.  Many of the concepts he helped develop form the basis for today’s approach to building more secure systems.

In the early 2000’s Steve suffered through CodeRed and Nimda, two worms that affected Microsoft Internet Information Server 4.0 and 5.0.  In January 2002 when Bill Gates issued his “Trustworthy Computing memo” shifting the company’s focus from adding features to pursuing secure software, Steve and his team went to work training thousands of developers and started a radical series of “security pushes” that enabled Microsoft to change the corporate culture to emphasize product security.

Steve likes to joke that he started running the Microsoft Security Response Center (MSRC) when he was 32; the punchline being that the retirement-aged person he is today is strictly due to the ravages of the job. Microsoft security was once called one of the hardest jobs out there and Steve’s work is truly an inspiration.

The Security Development Lifecycle (SDL) is the process that emerged during these security improvements.  Steve’s team has been responsible for the application of the SDL process across Microsoft, while also making it possible for hundreds of security organizations to adopt, or like Adobe, use it as a model for their respective secure product engineering frameworks

Along with Michael Howard, Lipner co-authored of the book The Security Development Lifecycle and he is named as inventor on 12 U.S. patents and two pending applications in the field of computer and network security.  He served two terms on the United States Information Security and Privacy Advisory Board and its predecessor.  I’ve had the pleasure of working with Steve on the board for SAFECode – The Software Assurance Forum for Excellence in Code – a non-profit dedicated to the advancement of effective software assurance methods.

I’d like to thank Steve for all of the important contributions he has made to the security industry.

Brad Arkin
Vice President & CSO

 

Adobe @ the Women in Cybersecurity Conference (WiCyS)

Adobe sponsored the recent Women in Cyber Security Conference held in Atlanta, Georgia.  Alongside two of my colleagues, Julia Knecht and Kim Rogers, I had the opportunity to attend this conference and meet the many talented women in attendance.   

The overall enthusiasm of the conference was incredibly positive.  From the presentations and keynotes and into the hallways in between, discussion focused on the general knowledge spread about the information security sector and the even larger need for more resources in the industry, which dovetailed into the many programs and recruiting efforts to help more women and minorities, who are focused on security, to enter and stay in the security field.  It was very inspiring to see so many women interested in and working in security.

One of the first keynotes, presented by Jenn Lesser Henley, Director of Security Operations at Facebook, immediately set the inspiring tone of the conference with a motivational presentation which debunked the myths of why people don’t see security as an appealing job field.  She included the need for better ‘stock images’, which currently portray those in security working in a dark, isolated room on a computer, wearing a balaclava, which of course is very far from the actual collaborative engaging environment where security occurs.  The security field is so vast and growing in different directions that the variety of jobs, skills and people needed to meet this growth is as much exciting as it is challenging.  Jenn addressed the diversity gap of women and minorities in security and challenged the audience to take action in reducing that gap…immediately.  To do so, she encouraged women and minorities to dispel the unappealing aspects of the cyber security field by surrounding themselves with the needed support or a personal cheerleading team, in order to approach each day with an awesome attitude.

Representation of attendees seemed equally split across industry, government and academia.  There was definitely a common goal across all of us participating in the Career and Graduate School Fair to enroll and/or hire the many talented women and minorities into the cyber security field, no matter the company, organization, or university.   My advice to many attendees was to simply apply, apply, apply.

Other notable keynote speakers included:

  • Sherri Ramsay of CyberPoint who shared fascinating metrics on cyber threats and challenges, and her thoughts on the industry’s future. 
  • Phyllis Schneck, the Deputy Under Secretary for Cybersecurity and Communications at the Department of Homeland Security, who spoke to the future of DHS’ role in cybersecurity and the goal to further build a national capacity to support a more secure and resilient cyberspace.  She also gave great career advice to always keep learning and keep up ‘tech chops’, to not be afraid to experiment, to maintain balance and find more time to think. 
  • Angela McKay, Director of Cybersecurity Policy and Strategy at Microsoft, spoke about the need for diverse perspectives and experiences to drive cyber security innovations.  She encouraged women to recognize the individuality in themselves and others, and to be adaptable, versatile and agile in changing circumstances, in order to advance both professionally and personally. 

Finally, alongside Julia Knecht from our Digital Marketing security team, I presented a workshop regarding “Security Management in the Product Lifecycle”.  We discussed how to build and reinforce a security culture in order to keep a healthy security mindset across a company, organization and throughout one’s career path.  Using our own experiences working on security at Adobe, we engaged in a great discussion with the audience on what security programs and processes to put into place that advocate, create, establish, encourage, inspire, prepare, drive and connect us to the ever evolving field of security.  More so, we emphasized the importance of communication about security both internally within an organization, and also externally with the security community.  This promotes a collaborative, healthy forum for security discussion, and encourages more people to engage and become involved.

All around, the conference was incredibly inspiring and a great stepping stone to help attract more women and minorities to the cyber security field.

Wendy Poland
Product Security Group Program Manager

View of an Internship with ASSET

I technically joined the security community last year when I began my Master’s in Information Security at Carnegie Mellon University. I gained a lot of theoretical and practical knowledge from the program, but my internship with ASSET gave me a totally new perspective on how security in a large organization works. I worked on multiple projects over the summer in the beautiful city of San Francisco. I have outlined one of them below.

Adobe follows a Secure Product Lifecycle (SPLC).To cater to the large number of current and future Adobe products, the security guidance provided to the teams by ASSET needs to be scalable. Scalability requires automation, or else the number of security researchers and their time becomes a bottleneck. Security guidance is also intended to focus on the configuration of the projects. For example, a Web service written in Java that handles confidential information requires a very different set of guidelines to follow as compared to an Android application.

For such targeted guidance, we use a smart system called SD Elements. For SD Elements, I performed a gap-analysis on security recommendations of Android and iOS apps as well as on desktop and rich-client applications. I researched quite a bit in the process. Some of my sources included the CERT guidelines for securing applications, internal pen-test reports, and a lot of academic research papers and vendor reports. Adobe has now moved to cloud deployment for many of their products: Creative Cloud and Marketing Cloud are prime examples. To support this recent momentum, I also expanded the deployment phase in SD Elements which is a set of guidelines for DevOps teams to securely deploy and maintain their applications in the cloud.

During my internship, I worked with Mohit Kalra who was my manager and Karthik Raman, my mentor. They were always available to guide me whenever I got stuck on a problem and always gave me specific Adobe context. My other team-members were also very helpful and considerate throughout the internship and they always made me feel at home. As part of Adobe Be Involved month, I also got a chance to volunteer at Edgewood Center for Children and Families, which was a humbling experience. We played kickball with the kids and it was really great to see smiles on their faces.

Mayur blog post

Volunteer picture from Edgewood Center for Children and Families. (I’m the guy in bottom left.)

As a result of my internship at Adobe, I feel like I’ve really improved my technical knowledge and my understanding of how security works within an organization. Thanks, Adobe.

Mayur Sharma
Security Intern

Using Smart System to Scale and Target Proactive Security Guidance

One important step in the Adobe Secure Product Lifecyle is embedding security into product requirements and planning. To help with this effort, we’ve begun using a third-party tool called SD Elements.

ADO867-Security-SPLC_V1-live

SD Elements is a smart system that helps us scale our proactive security guidance by allowing us to define and recommend targeted security requirements to product teams across the company in an automated fashion. The tool enables us to provide more customized guidance to product owners than we could using a generic OWASP Top 10 or SANS Top 20 Controls for Internet Security list and it provides development teams with specific, actionable recommendations. We use this tool not only for our “light touch” product engagements, but to also provide our “heavy touch” engagements with the same level of consistent guidance as a foundation from which to work.

Another benefit of the tool is that it helps makes proactive security activities more measurable, which in turn helps demonstrate results which can be reported to upper management.

ASSET has worked with the third-party vendor Security Compass, to enhance SD Elements by providing feedback from “real world” usage of the product. The benefit to Adobe is that we get a more customized tool right off the shelf – beyond this, we’ve used the specialized features to tailor the product to fit our needs even more.

We employ many different tools and techniques with the SPLC and SD Elements is just one of those but we are starting to see success in the use of the product. It helps us make sure that product teams are adhering to a basic set of requirements and provides customized, actionable recommendations on top. For more information on how we use the tool within Adobe, please see the SD Elements Webcast.

If you’re interested in SD Elements you can check out their website.

Jim Hong
Group Technical Program Manager