SD Elements | 
Research
Upcoming Events
Resources
The Balancing Act is our podcast series that hosts interviews with security practitioners on the challenges they face and their personal journeys. As part of the Security Leaders series of The Balancing Act, Security Compass’ CEO, Rohit Sethi sat down with Timo Skytta.
Timo is a Managing Director and Head of Advisory (Security) for Goldman Sachs. He leads the team in assessing new technology initiatives for risk, partnering with engineers to architect and design secure products and services. Prior to joining Goldman Sachs, Timo held senior technology and security leadership positions at Nokia, HERE, and Verizon Media. During his career, he has built and led software engineering and security teams building and supporting large-scale mobile and internet services.
You will find the entire podcast interesting. Below are some of the highlights.
1. Timo’s broad experience helps his security work
Timo only moved into security in 2009. Before that, he worked in various roles in Europe and the US. After receiving his BSc from Oulu University, his first job was in PC support at IBM, and he spent several years in networking. At Cisco he was frequently working with sales as the customer-facing technical resource. During his nine years with Nokia, he ran engineering teams, led their Internet Standardization initiative, and was Head of Technology Strategy and Management prior to taking on the CISO role. Understanding the scope of business needs and priorities across functional areas provides him perspective in security discussions with stakeholders outside of security.
2. Workload management is a constant pressure
In every team Timo has managed, there has been a constant need to balance workloads. Timo sees workload pressure as more than just the sheer number of tasks security teams must address or staffing shortages. Another factor is the team’s commitment to security. “Most of the security people are very proud of their work and they feel very much that they are responsible for the security of the company’s reputation and individual products. And that also often leads to a way of working where people take their responsibility very seriously, and overload themselves with the work.”
3. Strategies for priority management with product owners
Timo has worked with teams running waterfall and agile development processes, and making sure security is plugged in at the right times and levels is critical. So too is working with product teams to ensure priorities and expectations are understood. One strategy he has used successfully is sprint planning for the product security team. They used “normal software engineering methodology where each one of the engineers has 10 points that they can allocate for the two weeks” In addition to planning for tickets like official review requests and audits, the team could allocate points (days) for ad hoc or non-ticketed work where they:
“ [Allocated time for the sprint] knowing that during the next two weeks you’re going to be…working closely with the engineering team on the design. No reviews, no formal Jira tickets, but you’re going to spend that time on design with them.”
Two benefits resulted. First, it made the workload and priorities known to all personnel involved in product development and security. When extra work or overloading of certain personnel was required, they knew that before the sprint began and when the overloading would end. Second, when unanticipated requests came from product owners or development, they had a plan that was “visible and defensible” to facilitate an informed discussion across the teams and with management. In Timo’s words: “Here are the things we have committed to do for the next two weeks. Which of these things do you think are less a priority than your request, and why?”
4. Leveraging automation to stretch resources
“Automation is key to scaling.” Timo also sees two challenges. The first is the complexity of modern deployments. The second still surprises him; he believes security professionals prefer to check things personally instead of relying on automation. This ties in with his view that security feels personally “responsible for the security of the company’s reputation and individual products”.
His solution is to split the process, applying automation to those projects that he can then reserve and focus his key resources on the “core enabling services that build the security and technology foundation for the company and then on those core services that make the money for the company.” To do this without compromising security required a requirements and review process that could be used by development teams, along with self-attestation where development teams “attest to certain in-depth, actionable requirements with evidence that you’ve done what is required [and] the security team do audit checking.”
The requirements for engineering needed to be “Actionable by the engineering team so that they do understand what needs to be done, they have examples of what needs to be done, and they know who to reach out if they still have questions”. Automation works for his teams “because I gave them requirements in their natural environment in a form that they could consume and work with”.
Listen to the entire podcast here.