Vice President of Engineering Ken Okumura manages engineering and operations infrastructure at TRUSTe, a provider of technology products and services that business customers use to manage their data privacy practices. His security-focused career track has also included roles at Qualys, Inc., Postini, and Verisign, where he was one of the first employees hired. Okumura spoke with TechBeacon Chief Editor Robert L. Mitchell about developing apps with privacy in mind, tackling the talent shortage, and how hosting an engineering group in the Philippines has helped create a stronger, more cohesive team.
TechBeacon: What role does software engineering play in your business?
Ken Okumura: Providing the technology to streamline the workflow necessary to accomplish best privacy practices is where software engineering comes into play. Also, the services-oriented nature of what we do allows us to provide the infrastructure necessary to deploy this at scale.
TB: You have a background in security and privacy. What do software developers most often get wrong when it comes to security?
KO: It's simple things like front-end data entry, where users are allowed to insert executable statements into fields that were not intended for such use, resulting in SQL injection attacks. Developers should be doing checks on the front end to prevent this, assuming that the front end didn't catch it, and doing checks on the back end as well. People don't always put in the necessary measures to protect against these types of things.
TB: Why should developers focus on building in privacy when creating new software?
KO: There need to be assurances that data is handled in a safe and responsible manner. Today, an exchange of information with someone in a face-to-face transaction is very different from exchanging that same information on a form on a website. That should not be the case. That same level of trust needs to be online as well. Because of the speed at which information proliferates online, it is even more important to safeguard that information. When you read about the latest security or privacy breach in the news, it should remind you that safeguarding privacy is more important today than ever before.
TB: What path did you take that led you to become vice president of engineering?
KO: I started out as a software engineer and eventually ended up on the management track. Although I enjoyed designing software systems and writing code, bridging the gap between the needs of the business and building systems to satisfy those requirements were better served when I moved into a management role. I am still able to roll up my sleeves and solve challenging technological problems, but at the same time I interact more closely with customers to ensure that their requirements are met.
TB: What is your typical day like?
KO: It is filled with interactions with the engineering team, discussing projects and system architecture, and meeting with other cross-functional groups within the company to discuss projects and customer-facing tasks. I get to remain close to my technical roots and help the business at the same time.
TB: What are the biggest challenges you face right now?
KO: We are trying to solve very difficult problems. The spotlight is on privacy and security, so we have to ensure that we are true to our mission, building systems with integrity while ensuring that our customers can use these systems in an unencumbered way.
TB: You're located in the San Francisco Bay Area. How do you find the right people to join your development team, given the talent shortage there?
KO: The hiring climate is very competitive in the Bay Area, which makes it more difficult to get things done in a timely manner. I don't have a magic answer. I talk to everyone I know and ask them. This morning I was on LinkedIn and typed in a tech keyword and a couple of names popped up. I noticed some similarities with one of the backgrounds and someone I knew. It was not a connection that the system found. It was something that I recalled from a conversation years ago. I asked the person I knew and it turned out to be his nephew. I was able to talk to him directly. You just never know what connection you might make. We use a lot of recruiting help here. They face the same challenges, but they have better recruiting tools, and better processes and connections.
TB: You moved some development work overseas. Was that a response to the talent shortage in the Bay Area?
KO: We did form a team abroad, but we didn't seek to do that. Someone I know and trust relocated to the Philippines. I had a project, I reached out, and it grew from there.
It was the perfect storm for us. The talent pool was there, they have reasonable rates, and everyone speaks English. We just happened on a good situation. But you need to make sure you follow the practices in that country and don't get into trouble. Just as there are nuances in developing systems with an international workforce, there are also nuances in developing systems that reach customers internationally. For example, there are certain combinations of data that we don't consider personally identifiable information in the US, but other countries do. We're always looking at international regulations.
TB: What challenges does having part of your team in a different country present, and how do you overcome those challenges?
KO: The most challenging part has been the time zone differential. That said, there are also benefits of having development and quality assurance done continuously for 16 hours or more per day. We have many meetings online and travel back and forth frequently. This has made the team more cohesive. As a result, we are able to work together very effectively despite the time zone challenges.
TB: How does TRUSTe's focus on privacy—and your background in security—affect how you build software?
KO: We develop our systems from the ground up with both privacy and security in mind. We have many people on the team with security in their DNA, and it's important to leverage philosophies used to develop security-focused systems when designing systems with privacy in mind. You always have to assume that at some point your infrastructure may be breached. You have to be mindful of the data that you store, some of which might be privacy-sensitive or business-sensitive, and ensure that you put extra safeguards in place that would nullify the effects of a breach.
TB: What project are you working on right now?
KO: We are developing a SaaS-based product called Assessment Manager that helps enterprises manage their data and privacy programs across their businesses in a responsible manner. We are taking something that's manually intensive and applying technology to it. Often, when data flows from asset to asset you don't have a paper trail. Data goes into a system in another country and you don't even know it. We are turning a process that is highly manual into an automated electronic process.
Building the product is very complicated because every company's process is different. We use agile methodology, which has been working nicely. As we build and tweak the systems, customers tell us things that let us continually improve the system. It's a learning process on both sides. We're trying to assess each business' privacy stance and how they handle their own data.
TB: How do you ensure that user experience is the best it can be for your customers?
KO: We continuously engage our customers in the development process. Part of being an agile shop is doing this on a regular basis. Our product, QA, and DevOps teams work in sync with the development team to ensure a smooth transition from development to production.
TB: Are there areas where you've customized process beyond what you might learn in the standard agile and DevOps playbook?
KO: It's not as simple as having an engineer throw the code over the wall to the ops guy, who installs it. There are some assists along the way. The engineer works with the ops guy and says, "Have you thought about doing it this way?" We've tweaked DevOps a bit in that way. The teams must work together closely. The technology stacks are constantly changing too, so you have to take into consideration development's concerns about code, and there's a commingling and sharing of ideas that makes the process highly customized.
TB: How does the software development process change as you move from on-premise to SaaS-based offerings?
KO: SaaS-based offerings are very powerful, because you can have a large positive impact on many customers simultaneously. You can do major releases or small enhancements on a continuous basis. There is no concern that different customers may be using different software because of the nature of a cloud service. At the same time, you have to remember that when you do development, you can negatively affect all of your customers at the same time if you are not careful. You have to be very thorough with your quality assurance process.
TB: Tell me about a failure you had to work through and what you learned from that
KO: I worked on a system at a previous company where one of the engineers circumvented the normal release process and decided to push what he thought was a simple, one-line code change to production. He ended up bringing down the whole system. Although bringing the system back to its previous good state was simple, the damage was bad, as downstream transactions had to be corrected. Luckily, we were able to use a manual corrective process.
When you're in a startup environment, developers are used to having access to production. When you're developing enterprise software and services, however, you can't allow unencumbered, full access.
In this case, the engineer felt empowered to do something on his own, but at the same time did not follow process. We learned that there is no such thing as a simple code fix, and that it's very important to follow process, no matter how small or trivial the change may appear to be. Checks and balances are there for a reason.
TB: What's a little-known fact about you?
KO: I studied architecture in college before I discovered computer science. Both disciplines require a technical foundation in addition to creative problem solving, so the transition was not too much of a stretch.
Image source: Flickr
Keep learning
Learn from your SecOps peers with TechBeacon's State of SecOps 2021 Guide. Plus: Download the CyberRes 2021 State of Security Operations.
Get a handle on SecOps tooling with TechBeacon's Guide, which includes the GigaOm Radar for SIEM.
The future is security as code. Find out how DevSecOps gets you there with TechBeacon's Guide. Plus: See the SANS DevSecOps survey report for key insights for practitioners.
Get up to speed on cyber resilience with TechBeacon's Guide. Plus: Take the Cyber Resilience Assessment.
Put it all into action with TechBeacon's Guide to a Modern Security Operations Center.
