techbeacon.com-coding-privacy-conversation-trustes-ken-okumura (20160911)
TRANSCRIPT
The TechBeacon interview Jul 1, 2015
Get the Report
Coding for privacy: A conversationwith TRUSTe's Ken Okumura
REPORT: 2015 Gartner MagicQuadrant for Application SecurityTesting (AST)
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
Topics: Agile, App Dev
Share this article
Show More
security privacy
Software engineering agile
Recruiting DevOps TrustE
Ken Okumura
More by Robert L. Mitchell
All open, all the time
The 8 best open-source tools forbuilding microservice apps
Take this app and...
5 reasons why users are ready totrash your app
Article Tags
Robert L. MitchellManaging Editor
TechBeacon
3 articles
Follow @rmitch
Subscribe to TechBeacon
Get fresh whitepapers, reports, casestudies, and articles weekly.
Enter your email address
! SUBSCRIBE
Newest | Oldest | Top Comments
Sign in 2 people listening
Related Articles
The elusive agile enterprise: 5leading experts tell you howto get it doneSelling agile at scale
JavaScript vs. otherlanguages: Live long andprosper?Beyond the browser
14 languages that help youblock entire error classesBug repellent
39 Java experts you shouldfollow on TwitterJam-packed with Java
Developer certifications: Ifyou can code, do you reallyneed them?Friend or foe?
Rewrites vs. refactoring: 17essential reads for developersHot mess
21 dangerous pieces of codeand programming misstepsSitting on a powder keg?
Moving beyond MVP: 5 agiledesign practices you can'tafford to ignoreDesigned for coding
18 fascinating developer warstories and postmortemsReading roundup
4 ways to engage developerswho couldn't care less aboutsecurityMake the wake-up call
5 things software engineersneed to know about big dataBig advice
Outages happen: 4 ways toprevail over your next bigsystem failureWing and a prayer
Topics TechBeacon
" # $
Brought to you by
0 comments
Post comment as...
⋆
⋆ ⋆
⋆ ⋆
⋆