Opinion

Introspection, Growth and Passion

Having a moment of introspection this morning, thinking back over the years of how my work has changed – sometimes in pretty dramatic ways. It seems like forever ago that I was fresh out of school and working my first real programming job at a domain host. I worked hard until I was ultimately let go from the role due to some interpersonal issues. Fortunately, the market was good and I found a new role with a natural gas provider relatively quickly. I did a lot of growing there, not only in my skills but just in my understanding of how business gets done. It was while I was there that I got married and soon had to figure out how to juggle work and kids, finally getting it down about the time the second one came around.

All the while, I was still working on my passion – programming and learning how to make “better” applications. I think at the time I didn’t know what “better” meant in the context of PHP applications but I spent a lot of time reading up on the subject and, yes, attending conferences (my first was php|tropics which I still can’t believe my employer paid for to this day). I made friends in the community, both local and national – even some international – that helped me build my skills. They were there when I had questions about how to create something and regularly had books, blog posts and other recommendations for resources to further my understanding of what “better” meant. I was constantly improving and moving up the ranks from junior developer to senior developer then lead developer and, yes, even a manager of a development team (it was weird).

Fast forward a few years to about five years ago. I sat back and looked over my career so far. I really looked at the work that I’d accomplished over the years, how I’d grown in my understanding of what “good code” and well-structured applications meant. I understood some of the higher level development concepts (like SOLID) and how to effectively apply them in my day to day work. I was co-organizaing the local PHP meetup, had started sharing my knowledge at conferences and through books and several articles on a wide range of topics. But I’d hit a problem that Young Me hadn’t thought was possible: I felt like I was stagnating.

I looked at the work I was doing (a security company but doing PHP development, not application security) and, while I was enjoying it and the people I was working with, there was something nagging in the back of my mind. It wondered if this was where things leveled out and the only way up was to a less technical role. I’d always been driven by the tech and exploration, so at the time that was a non-starter. I needed to find something that would fill my need for more tech and more exploration but I didn’t know exactly what.

I looked around at the work I was doing and the industry I was in and realized what I needed. I needed to specialize. I needed new challenges that both appealed to my desire to stay in the tech of things yet provided me with room to explore other things. I’d always had a passion for security (as anyone that knows me can tell you) so it seemed like a good option. I started to do more research and learn everything I could about the current state of application security. I’d had a cursory knowledge of it in the past but I really doubled down, watching recorded talks, reading tons of articles and even giving/writing some of my own (the best way to learn is to teach, right?).

So this was my first pivot. After I muddled through one role that didn’t turn out to be what I was hired to do, I ended up landing an application security job at a larger company. The group I worked for was a smaller acquisition of this company so it still had that “small company” atmosphere. I was still learning as much as I could and was being challenged daily to put this knowledge to the test. I worked with a great team of other security folks and engineering groups in a culture of mutual respect and growth. Unfortunately, some things changed with that role and I ended up leaving, going to my second position as an Application Security Engineer. I wasn’t doing as much development work as I had in the past outside of building some custom testing tooling, but I spent time outside of work scratching that itch.

I’ve been at my current role for over a year now and, while the work is interesting and I am working with a wide variety of tech and learning something new just about every day, I’m starting to feel that same nagging feeling in the back of my head. When I sit down and actually think about what that voice might be telling me, it’s an interesting story. I look back at how I pivoted before. I made use of my years of development background and turned it on its head, focusing on how to use it to understand the structure of applications and how to best work with development teams to improve their overall security.

One of the things that appealed to me the most about the role I’m in is the training program. There was already a program in place, started a year or so before I began there, to internally teach the development groups about application security-related topics. At this point I’d been a speaker and a “teacher” for years in various ways: conference presentations, mentorships, and writing plenty of tutorials and blog posts. I’ve always been excited to share my knowledge with others and delight in seeing that lightbulb go on behind their eyes when they really “get” a concept. I was excited to be able to be a part of that program. I presented the current courses numerous times and even worked up a new “advanced” full-day training to provide even more of an in-depth look at application security for our Engineering staff.

Some things have changed, however, and the team I’m on won’t be involved in the training program as much as before and I’d be lying if I said I wasn’t disappointed. There’s some additional context needed here that might help you understand why this is difficult for me. It has to do with that little voice again. See, a few months back, my excitement about the AppSec training program was really ramping up. I’d given the new course several times and had worked on efforts to help improve the program and processes around it. The excitement was so much so that I finally figured out what that voice was talking about and I applied to graduate school – and was accepted – at the University of Massachusetts (Boston) for a certificate in Instructional Technology Design, focusing on using technology to improve the learning process and experience. It was only after this, however, that things changed in my role and my team was less involved in the program. I won’t get too into it here but you can understand my disappointment. I’d figured out the next pivot that voice was urging on: taking the development background, combining it with the application security perspective and sharing that with others in an interesting, relevant, and effective way.

Being on a different team hasn’t stopped me, though. I still find places to help out where I can and try to make some kind of impact on the program when possible, it’s just not a direct influence. I don’t want all of this to come off as complaining. Despite what my current role’s focus might be, I’m still pushing on, learning as much as I can about learning and development, even if it’s just to apply it to my next conference talk or potential online training sessions. I feel the drive to learn again and it’s refreshing. It has already filled in some blanks for me that I was missing in my own instructional methods and has given me countless more to explore. I’m excited to see where this all will lead me.

I wanted to share my story here, not because I feel like it’s important or that it’s any kind of amazing. I wanted to share it for those out there that might have that little same voice inside their heads wondering “what’s next”. I share it because I want to show that it’s not always about becoming the “best of the best” in a single kind of role. As the saying goes: if you’re the smartest person in the room, you’re in the wrong room. It’s scary to think about change, especially in the tech world where change doesn’t always go so well and things can be unpredictable. Don’t be afraid to take a step back and look at what you’ve accomplished and where you’re headed. Make sure it’s what you want and really think about your future.

I look back on my over almost 20 years of work in technology and think about how far I’ve come in that time. I think about the “what if” of having stayed in that same role I was in years ago and where I’d be now and, honestly, I wouldn’t trade the experience and changes my career has gone through for anything. It has helped me become the person I am and has helped me find my passions along the way and, even now, is driving me on to learn more and grow. I hope that you can find the same kind of excitement in your work and can find what you’re passionate about, regardless of your current role and, most importantly, you don’t ignore that inner voice that could be guiding you towards something where you’ll find joy.

Saying Thanks – Open Source Appreciation

Wow, it has been a really long time since I’ve posted here. Most of my writing has ended up in articles of php[architect] or over on Websec.io. I wanted to jump back into the blog though and talk about something inspired by a post over on the Symfony blog about giving thanks.

Normally the Thanksgiving holiday is more associated with sharing what you’re thankful for in your life. However, the Christmas holiday comes at a perfect time to look back over the past year and think about everything you’re thankful for and how your life has changed, hopefully for the better. In the Symfony blog post they share a Composer plugin – Thanks – that makes it simple to show your appreciation to those packages you’re currently using in your applications. It sends stars to the projects (the ones you haven’t already starred naturally) as a token of appreciation. This is a great first step to showing how much you appreciate the work the maintainers have done but there’s also other ways to show that you support them and that they’re doing a great job. Here’s a few other suggestions:

  • Find their email (often in the repo’s README.md file) and send them a quick note telling them how much you enjoy using the library and how important it is to your application.
  • Write a blog post about the package and how you use it to share with others. Maintainers always enjoy seeing how their work is used and maybe even get ideas for future features and fixes.
  • Send out a Tweet about the project, telling them how much you appreciate the work they do.
  • Support them on Patreon if they have a page on there with a recurring donation. This allows them to spend more time focusing on the project and making it better for everyone.
  • Open an issue on the project’s Github/Bitbucket repository with a quick “Thanks” to everyone involved.

These are just a few ideas to get you started, of course. There’s plenty of other ways that you can support and thank the authors and maintainers of your favorite packages. Get creative and think of your own but this is the perfect time of year to do it and let those developers know their work is appreciated!

An Open Suggestion to OWASP (or How to Bridge the Gap)

In a previous post I made a call out to the security community (mostly the OWASP group) about some of the lacking involvement in the world of PHP. There were some good comments on the post, and there’s some I’d like to give my own feedback on to maybe explain things rolling around in my head even better.

First off, there was the comment I knew was coming even before I hit the “Publish” button. In this comment Ryan turns some of my comments back around and wonders if the lack of PHP involvement by OWASP is more of a reflection of how much involvement the PHP community has with it. While I agree with this to a point, I’d also suggest that it has to be a two way street when it comes to communicating effectively with developers. An organization that wants to provide information about how to secure applications should be involved with the groups it’s trying to help. Likewise, that group can’t effectively provide the information developers are looking for without guidance from those developers themselves. After all, what good would a guide about not using “safe_mode” be to people using PHP 5.4.0+? More on this topic later…

Another comment brought up a few more specific issues around the tooling that the OWASP group provides, suggesting that it’s less attuned to what PHP developers actually need and is more of a direct port of an existing Java or .NET version of a similar project. The influence is definitely there and it makes me wonder how much PHP experience the author had in the language (not just writing PHP but actually knowing PHP…there’s a difference). The PHP community is a rapidly evolving one by the nature of the language and if you’re not keeping up with trends, advancements in the language or where the state of security in the language is at, your tool will be deprecated before it even hits 1.0.

Finally there’s the comment I hoped I’d get from a representative of the OWASP group themselves, a member of the board no less, Michael Coates. I’m glad that the response was one of openness and a desire to make things better. It’s easy to see how, especially in a community that tends to err on the side of keeping things under a rock, that the group I was mentioning was paying attention. Michael’s comment asks for direct suggestions about things that can be done to help the situation I put out there. With the somewhat wide chasm between the two words, I can see a lot of room for improvement, but I think there’s one suggestion I’d make to Michael and the rest of the OWASP folks (including those already involved in PHP-related projects under the organization):

Get involved.

Sounds simple, right? Honestly, I think the biggest problem here is the communication between the two groups. I feel like the OWASP group, while having good intentions, sometimes comes across as more of a “we’re security professionals and we know how to write the tools correctly” kind of mentality. As a result, you end up with projects like the PHP ESAPI  or the work being done on the PHP Security Project that’s recreating tools that already exist in the PHP ecosystem for the sake of having a “one tool to rule them all.” Essentially what it ends up being is a mish-mash of tools that a developer could use to secure their applications. What it doesn’t end up being is a useful tool that PHP developers want to use to secure their applications.

The goals of the project are admirable, but their time could be much better spent encouraging the package mentality the PHP community has evolved over the past few years and enhance the security features of pre-existing and well-tested/vetted libraries already in wide-spread use. Let me illustrate with a list of things the owasp/phpsec project includes that already have packages that solve the problem:

– a database abstraction layer (not an ORM or even ActiveRecord, just a layer on top of PDO)

– a “download manager” that seems to not do much more than stream a file to the given output

– an encryption class that does some crazy stuff to encrypt a string

– A HTTP request class that most frameworks have anyway (or even HttpFoundation)

– A Logging class that can output to a database, file, mail or syslog (or just use Monolog)

– A cryptographically secure random number generator (how about RandomLib instead)

– A sort of “security scanner” that looks for a limited set of keywords (try Parse instead)

– A session handler that forces database use and doesn’t plug into the SessionHandler interface

There’s a lot of other features in the tool that could go on this list too, but it feels like there’s just a big disconnect here between the goals of the project to provide a useful library PHP developers will want to use. While I get the whole idea that other packages are “written by developers and not security experts”, there’s a lot of things they’re reproducing here that have already been solved.

So, my suggestion to the group working on the PHP Security Project is this – stop with the Not Invented Here development and get involved in the work that’s already been done to make these “decoupled libraries” people are actually using. Help show the PHP development community that you’re interested in being a guiding force for security concepts and techniques rather than building something in a silo most developers would never even use.

The PHP community gets better tools and OWASP gets known in the community as an organization that cares about keeping PHP safe. Seems to me like this is a win/win situation for both sides.

“It Depends”

In my research and writings that I’ve already done, I’ve noticed something about trying to share helpful security advice to fellow developers – you can provide all of the code examples and describe the threats all you want, but the problem really boils down to two words:

“It depends”

Much like other development-related issues, there’s a lot of things you have to take into consideration when thinking about the security of your application. Code security by itself is good, and there’s some best practices for that that have been shared all over the web. Unfortunately, this only paints a small part of the picture. Web applications, by their nature, are really complex systems composed of multiple pieces of software all running together to make this useful, functional service for its consumers. If you’re a PHP developer, there’s things you can do to help prevent common attacks (like XSS, CSRF or SQL injection to name some popular ones), but unless you look at the bigger picture, you’re getting a false sense of security.

“But I’m only responsible for the code!” you say. You like the idea that your code can be as secure as possible by filtering output, escaping user input and using defensive coding techniques. You commit your code, run your tests and happily go about your business, thinking things are good. Unfortunately, if you don’t consider the ecosystem your application lives in, chances are you missed something.

I’m not talking about code challenges here – preventing things like XSS or SQL injections is relatively easy (as long as you know what to do). The problems I’m talking about are things that may be true for one environment but not for another – things like:

  • Working with multiple databases and storing their credentials securely
  • Effective logging to a remote syslog server
  • Potentially protecting your data from a physical intrusion
  • Working with sensitive data
  • Bridging authentication/authorization across applications
  • Concurrency issues coming from multiple installations of the same application

While a lot of these kinds of concerns revolve around the architecture of the application, developers still need to keep them in mind when creating their applications. At the very least, you need to keep these kinds of concerns in mind when writing your code. Like anything else, there’s ways to structure the code to make things like this simpler to change. The trick is to keep things loosely coupled enough to make life simpler down the road.

Innovation’s Not The “Ah-Hah!”

After reading through his “Confessions of a Public Speaker” (as a beginning speaker, I learned some good things from this one – I’d suggest it if you do any kind of speaking) I was anxious to check out some of Scott Berkun’s other books. The topics of some of the others didn’t really appeal to me, but the one that’s caught my attention recently is his “Myths of Innovation” book. I’m maybe a third of the way through it right now, and there’s one thing that keeps resonating in my mind as I go through it. In a previous chapter, he makes the point that innovation, despite what the history books and popular culture would have us assume – it’s less of an “Ah-hah!” and more of a “Finally!”.

See, most of the common stories of innovators out there leave out something that’s very important – the reference frame of their lives. They don’t provide a larger picture of who someone is (like Einstein or Newton) and how all of their work, everything they’ve done in their career led up to the discoveries that they’re known for.

I think this is important to remember as software developers, too. All of us start projects and never finish them, it’s just a fact of life in the world of a coder. We find something that we either think is the “Next Big Idea” or something that we’ll find amazingly useful and latch onto it, giving it our all for a week, maybe a month. Nine times out of ten, though, that project falls by the wayside. Now, don’t get me wrong, there’s some folks out there that do a great job with anything they touch, but for the average developer, it’s all about hacking away at the latest “shiny”.

Sometimes it’s about the technology (“everyone’s learning Backbone.js, why shouldn’t I?”) and other times there’s a bit of pride that kicks in (“I could do this so much better if…”) but there’s always one thing to remember. It doesn’t matter if the project you’re working on goes anywhere. Remember this. Just like some of the great innovators of the past, it takes a lot of dedication and work to get to be the “Ah-hah Guy” that wows the world with something new and amazing. Don’t forget that the code of the Next Great App isn’t just going to fly from your fingertips.

Work hard at your craft and it will pay off. Maybe not in fame and glory, maybe in making real, useful contributions to the culture and technology around you. Don’t stop trying to innovate, don’t focus on the failures and, above all, keep learning and keep doing.