Once a professor shared a piece of career advice with me. "Don't call yourself a coder," he said, "anyone can learn to code, but programming takes real skill." His words have stuck with me since. Coding was, in his description, the mere act of producing something a computer can interpret and act upon. Programming, however, seeks elegance and simplicity through considered design and thought that transcends the code itself. While both take skill, the goals are different and they can be thought of as distinct disciplines.
Application Security, I've come to believe, is yet another discipline with a slightly different focus. 'Coders' focus almost exclusively on iterating until they achieve a desired result. 'Programmers' might test and refine to improve performance and reduce resource consumption. But with an Application Security perspective, we instead look at unintended functionality and edge cases that give rise to problems; 'What if' scenarios involving abuse cases that weren't part of the original design. It's yet another way of looking at the same application, with a different goal and different outcome.
At Matasano, we don't build software, we break it. We find, exploit, document, and prioritize flaws so the application's developers can address them. We identify when security controls are effective, and note areas for improvement. We review use cases, identify abuse cases, and help guide future development efforts. We work across a wide variety of applications ranging from simple web apps, to complex hardware appliances. From HTTP to proprietary encrypted protocols, and everything in between. As a team, we're as comfortable with ROP chains and memory corruption vulnerabilities as Cross-Site Scripting and SQL Injection. As individuals, we excel in our areas of focus while cross-training and broadening our skills. We're among the leaders in our industry and community, and give back through research, tools, and practice environments.
If improving the state of software security while kicking up some dirt in the process seems like fun, check us out. If you're fueled by pride of finding unexpected solutions, we have plenty of challenging problems for you. If you're not content to be a 'coder' and long for something more fulfilling, get in touch.
I've seen Matasano on here several times and I have to say, I really wish you'd reconsider your Remote working policy. It seems like such an interesting place to work, but for me personally, moving just isn't an option.
Your website lists 'Services' team-members as being required to work on a physical site, what other teams do you have? I am under the impression from your website that Services includes most Consultant and Penetration-Testing type positions; would you say that's correct?
A couple years ago, in our old office at the top of the Monadnock building, I'm working on code for a product we're doing while Vitaly is working on a pentest for a big Rails client, and, like, 5 other people in the office are working on 5 other things.
I'm procrastinating while noodling through some stupid Riak thing and so I hear Vitaly say something about how some request he sent to the app produced binary gibberish in the response.
It turns out I'd rather noodle around with Vitaly's app than figure out how to make Riak do whatever basic thing I want it to do, so I walk over and look at the response. Vitaly has already noticed that the "binary gibberish" is actually corrupted in the response headers; the response is corrupt.
We both agree out loud that this is unusual and bad. A couple other team members walk over. In the span of about 4 minutes we figure out that the bug is triggered by inputs that include NUL bytes, and responses appear to be corrupted at the point where the input is, in the headers, echoed in the output. And a few reloads show that what looks like gibberish is actually stale server memory.
This is that nginx bug that came out back when. It's approximately as bad as Heartbleed, except that it only affects nginx (and it has a more complicated trigger condition, albeit one that applies to virtually every web application). And because we were all together in the same room when Vitaly found it, we isolated, analyzed, and weaponized it in minutes, rather than in hours or days.
(Ironically, someone else had noticed the same bug on the same day, and [fair enough!] got the reporting credit.)
Stuff like that happened all the time at Matasano. The in-person requirement is one the company is unlikely to let go of --- not that I have any say in it anymore. ;)
"And because we were all together in the same room when Vitaly found it, we isolated, analyzed, and weaponized it in minutes, rather than in hours or days."
It wasn't because you were all together in the same room, it's because you were communicating effectively and you're assuming there is no way to replicate that level of effective communication without being in the same room.
With proper tools and training, everything you did in that room could have been done over the internet instead. There are communal whiteboarding apps, collaborative code editing apps, amazingly expressive chat apps like Slack, not to mention good old fashioned audio/video chat tools.
It can be done. It is done frequently, every day. It makes me sad to see so many people on a place like Hackers News, dedicated to building the internet's Next Big Thing repeatedly claim that it's not possible to collaborate as effectively on the internet.
I'm sure there's some amount of money and time Matasano could spend to make extra-office communication so fluid and effective that the sort of serendipitous collaboration I just talked about would happen with any two people on the planet. But, like most companies, they haven't. Meanwhile: they value that collaboration. So, there you are.
While is it true that the tools exist to collaborate equally well online vs. in person, the culture of an organization also needs to support it.
It is nearly impossible to just throw a new toolkit at a company and expect them to be able to thereby switch from an in person culture to a remote one.
It requires a transition of culture, which in turn requires both vision and support of the switch from the leadership of an organization.
Certainly remote collaboration works. But there is more to it than just flipping a switch or adding some tools.
Another aspect to consider is that given the sensitive nature of our work and access to what is often crown-jewel intellectual property, we have several clients who require we work from their offices. They are sometimes unwilling to cover travel costs. With a more geographically distributed base of employees we'd either have to eat the costs of bringing someone remote in for these projects, or rely more heavily on the now smaller subset of our staff that is present in these geographies. Neither is a desirable scenario.
Most of us like working in an office close to home, and don't like traveling a lot. It works for us.
"The in-person requirement is one the company is unlikely to let go of"
That's too bad, since this is a place that looks like it'd be very interesting to work at, but with no degree there's no chance in hell I'd be allowed to work in the US (at least so previous attempts have told me), and it looks like remote is a no-go.
For what it's worth, we often sponsor VISA candidates. I don't know the particulars of your case, but we have a number of employees who have come to the USA to work for us and do everything we can to support them.
All I can really say is that we have a culture of cooperation and interaction that relies, in part, on physical proximity. It may change in the future, but for now we prefer folks to be in the office where they can interact with others with less friction.
We're a lean company, so 'Services' encompasses all positions for which we're hiring.
I know you're just trying to build the best team you can, but in the interest of full disclosure every time I see someone say something like, "in the office where they can interact with others with less friction," all I see is "our team is bad at working remotely."
If you see remote as something that causes friction, I'd recommend looking at teams that swear by it reducing friction (like the friction of noisy offices and unnecessary commutes) and checking out the techniques they use to make it work so well.
Not every company is a good fit for every developer. For instance: I probably wouldn't like working at Valve. I do not however extrapolate that no company should be organized like Valve, simply because I wouldn't like it there. I am happy that there are companies like Valve that work well for the kind of people who are compatible with Valve, and companies like Matasano that work well for the sort of people who want to collaborate in person with a small, tight-knit group of peers and across the net with a larger group.
Gingerly, I'm going to go ahead and suggest that "incompatible with HN user 'kethinov" is not quite the dealbreaking deficit you're giving the impression that it is.
If you'd like to do appsec work remote, let me suggest Accuvant, Leviathan, and IOActive as alternatives. All three have remote teams. In fact, I believe everyone on the pentest team at Accuvant is remote. You never have to interact with your coworkers in person there at all.
We're not talking about subjective stuff like company culture, we're talking about factually disprovable statements like "you need to be in a physical office to collaborate effectively." That's an objectively false statement and it's irritating to see so many people repeat it.
I don't think either of the posts you've replied to in this thread state that all employees at all companies require physical proximity to collaborate effectively. Just that Matasano (by virtue of its leadership) prefers proximity.
It's entirely reasonable that some people prefer proximity over remote arrangements. People who don't aren't likely to enjoy working at Matasano. That doesn't negate the existence of other perfectly good options for them, as tptacek pointed out.
You don't think that "we prefer folks to be in the office where they can interact with others with less friction" is stating a requirement of physical proximity to collaborate effectively? That's how I read it.
Again: I'm assuming you're this invested in the thread because you really like the idea of working for an appsec firm. I don't blame you! Appsec is an awesome field to work in. I think you'd be much happier talking to Accuvant, which runs an all-remote team, than in trying to talk Matasano out of a carefully-made decision that is a core part of its culture.
I'm interested in this thread because it had so many instances of unstated premises hostile to remote work and I felt someone should say something to set the record straight.
It saddens me that you chose to ignore the substance of my argument and focus on visiting my intentions instead.
Hey I understand. You guys should be more upfront about Services encompassing all positions at this time. You had my hopes up lol. Best of luck finding candidates. :)
I had a quick look at your hiring process[1] (thank you for sharing this, btw).
I have a few questions:
* Are junior hires expected to be able to complete / pass all three challenges (pentesting, fuzzer, custom protocol analysis)?
* If not - how does the hiring / challenge process differ for junior hires?
* Assume good problem solving skills, effective (written and verbal) communication skills and an ability to program. What else do you like to see in a junior hire?
Ultimately, I'm trying to suss out the breadth / depth of self-instruction I need to undertake to pass interviews and perform successfully on the job as a new junior staff member at Matasano, or another selective / reputable company like it. Any other advice you could offer a developer making a transition to appsec would be much appreciated! :)
Best answer is to apply! We do some coaching at the start of the process and work with you to figure out how to get where you need to be. Some folks get through the process in a couple weeks, some take a couple years.
Less good (but easier) answers:
* Yes, everyone does all the challenges (though we've retired the fuzzer challenge, it wasn't a good predictor of consulting success).
* Our most successful candidates are motivated, curious, and clever.
Matasano Security - Chicago. New York City. Sunnyvale. Job Title: Application Security Consultant
-- .- - .- ... .- -. --- ... . -.-. ..- .-. .. - -.--
Once a professor shared a piece of career advice with me. "Don't call yourself a coder," he said, "anyone can learn to code, but programming takes real skill." His words have stuck with me since. Coding was, in his description, the mere act of producing something a computer can interpret and act upon. Programming, however, seeks elegance and simplicity through considered design and thought that transcends the code itself. While both take skill, the goals are different and they can be thought of as distinct disciplines.
Application Security, I've come to believe, is yet another discipline with a slightly different focus. 'Coders' focus almost exclusively on iterating until they achieve a desired result. 'Programmers' might test and refine to improve performance and reduce resource consumption. But with an Application Security perspective, we instead look at unintended functionality and edge cases that give rise to problems; 'What if' scenarios involving abuse cases that weren't part of the original design. It's yet another way of looking at the same application, with a different goal and different outcome.
At Matasano, we don't build software, we break it. We find, exploit, document, and prioritize flaws so the application's developers can address them. We identify when security controls are effective, and note areas for improvement. We review use cases, identify abuse cases, and help guide future development efforts. We work across a wide variety of applications ranging from simple web apps, to complex hardware appliances. From HTTP to proprietary encrypted protocols, and everything in between. As a team, we're as comfortable with ROP chains and memory corruption vulnerabilities as Cross-Site Scripting and SQL Injection. As individuals, we excel in our areas of focus while cross-training and broadening our skills. We're among the leaders in our industry and community, and give back through research, tools, and practice environments.
If improving the state of software security while kicking up some dirt in the process seems like fun, check us out. If you're fueled by pride of finding unexpected solutions, we have plenty of challenging problems for you. If you're not content to be a 'coder' and long for something more fulfilling, get in touch.
-- .- - .- ... .- -. --- ... . -.-. ..- .-. .. - -.--
careers@matasano.com or www.matasano.com for more info
-- .- - .- ... .- -. --- ... . -.-. ..- .-. .. - -.--
Curious about Crypto? - www.cryptopals.com Mesmerized by Memory Corruption? - www.microcorruption.com
-- .- - .- ... .- -. --- ... . -.-. ..- .-. .. - -.--