jjguy

You do have a lot to learn. So do I. So do we all. The universe of things that get posted to HN are too large for one person to master - it's why I still visit.

Lots of good suggestions here, but one I don't see is to simply narrow your scope. Choose one thing, make it your own. Keep it small, and soon you will find you can converse with that niche's recognized experts. Iterate on that theme and you will constantly expand your scope - in a few years you'll look back and realize you know a lot of things.

Tech could stand to take a cue from other disciplines. To his peers, a physicist is not just a physicist - she's nuclear physicist with a focus in particles, or a biophysicist with a focus in computational molecular modeling. Tech has the same de facto specialization, we're just changing too fast for the taxonomy to stabilize and become vernacular.

> After being informed of IBM's hundreds of millions in yearly patent revenue, CEO Steve Jobs authorized a change in FireWire's licensing policy. Apple would now charge a fee of $1 per port. (So if a device has two ports, that's $2 per unit.)...Intel sent its CTO to talk to Jobs about the change, but the meeting went badly. Intel decided to withdraw its support for FireWire—to pull the plug on efforts to build FireWire into its chipsets—and instead throw its weight behind USB 2.0, which would have a maximum speed of 480 megabits a second (more like 280, or 30 to 40 MB/s, in practice)...A month later, Apple lowered the fee to 25 cents per (end-user) system, with that money distributed between all patent holders. But it was too late. Intel wasn't coming back to the table. This was the death blow for FireWire in most of the PC market.

For all of you who embrace the "fail fast" mindset, keep this story close as a reminder that some mistakes are irrevocable. This was one decision, reversed after 30 days.

> However implication is that you would be happy putting in 50-60 hours

You're taking a too narrow a view of it. We never committed anyone to 50-60 hours, that's unsustainable. But by _allowing_ it and building a system to manage it, you let folks work what they want and still meet the client needs.

Without that flexibility, what happens is what OP describes - folks work more than 40 because you need to / want to, but you don't get compensated for it.

No, we'd never bill two clients for the same hour. Very few (no?) T&M arrangements where that would be legally/ethically/morally acceptable.

We simply let the team bill to multiple contracts. The contract & dev managers were responsible for authorizing the time and ensuring it was necessary/suitable/etc.

A typical T&M contract considers something around 1920 billable hours per year an FTE. 40 hrs a week, 4 weeks of vacation/sick time/etc per year. The typical way to manage those contracts at scale is hire one person per 1920 hours on a contract, then that person works exclusively on that contract.

We didn't allocate one person to a single contract, but fractions of a person - based on how much we estimated any given contract would need a certain set of skills:

"Joe's 20% on Project X and 80% on Y. Valerie's 100% on Y. Bill's 80% on Y and 20% on Z."

Of course, those are just estimates and nothing ever goes to plan - and it's always hard to hire enough good people. As a result, there were always opportunities for folks to do more work - either on their primary contract(s) or supporting another.

It makes the contract management harder, but it provides meaningful benefits to both the team and the clients.

In a past life, I ran a consulting team at a BigCo whose business centered on T&M contracts like OP's. BigCo had 10k employees, mostly associated 1:1 to contracts with the same "bill exactly 40 hrs, but never overhead" constrains.

Our little team had 100 employees, but we matrixed those guys across all our contracts. While the clients disliked the idea of not having "their guy," they really liked having access to the technical depth of 100 guys vs. just the 10 they could afford. Turns out being able to have a Linux kernel guy, OS X kernel guy, Android kernel guy, database expert and hardware hacker on call at all times is incredibly valuable.

Since we matrixed across contracts, we managed to instuitionalize the "overtime hack." The guys were exempt status, so they didn't get time and a half for hours over 40, but they did get paid for every hour they worked. It was a phenomenal hack - guys were routinely making 20-50% more than their base salary. We intentionally understaffed by a bit, to make sure there were always extra hours to burn.

That team is 15 years into existence at a BigCo, and the hack still lives. If you find yourself in a consulting org and think you can make something like this work, don't think for just yourself, but shoot for the moon - set it up so it works for everyone and outlasts you.

Einstein said it first:

If you can't explain it to a six year old, you don't understand it yourself.

https://www.goodreads.com/quotes/19421-if-you-can-t-explain-...

These are all standard security concerns. Anyone who brings you something similar and does not have a long list like this is in marketing or sales.

I spent twelve years as a "security guy" before becoming employee #1 at a now-wildly-successful security startup five years ago. I've spent a lot of time in the last year "professionalizing" our security program, now that we've grown large enough to need repeatable security procedures. I am intimately familiar with the domain.

Three things to segment the space:

- Clients are typically driven by compliance or practical security value. Understanding who you cater to and qualifying your customers will save a lot of pain.

- Many/most "pentesting" firms are focused on the corporate enterprise and IT people, not SaaS and dev people. Recognizing the difference in yourself and your customer needs will save a lot of pain.

- Many/most of the traditional IT enterprise security best practices & tools do not apply to a well-managed SaaS platform. e.g., I do not need a traditional vuln scanner to check for unnecessary and vulnerable services when I have one domain that's terminated at an AWS ELB.

Some industry color:

- The 2013 Target compromise root cause was not Target themselves, but their HVAC contractor who maintained trusted access. As a result, third party vendor risk assessment is becoming "standard practice" during the procurement process of any technology vendor, including SaaS applications.

- The vendor risk assessment teams expect all vendors to have mature security programs - SSAE-16 SOC2 audits, full Secure Development Lifecycle practices and customer-facing documentation to describe it all in detail.

- The result is a growing demand amongst smallish SaaS vendors for more professional security guidance.

With that context, some commentary on your original question:

- There are very few firms that provide good "practical security value." I cannot find enough good pen-testing firms that are a reasonable proxy for a capable attacker.

- The market for firms providing "compliance" services to "corporate enterprise IT" shops is noisy and full. The market for providing similar services to smallish SaaS vendors/developers is very sparse.

- The security tooling for dev is pretty good - static & dynamic source code analysis, tied into the build pipeline, etc. The security tooling for devops is not. There is a large gap in security tooling for devops/SaaS vendors - distinguished by automation and focus.

Finally, commentary on the question you're really asking:

- If you are world-class good, or can build a world-class team, you can build an outstanding company providing practical security value pentest services. Scale will be limited by the number of world-class staff you can hire/train.

- There is a gap in providing higher-level services to smallish startups to help them navigate third party risk assessment procedures from their customers. HN's tptacek and elptacek recently launched a new consultancy with this focus. They nailed the product/market fit. [a, b] Again, scale will be limited by the number of staff you can hire/train, but it is an easier team to grow than world-class attackers.

- There is a gap in security toolchains for devops/SaaS providers. Review the public projects from Netflix, Facebook and the other SaaS heavies for specific gaps _they_ had to fill. Every one is a product waiting to happen.

Cheers, and good luck.

a - https://latacora.com/

b - https://news.ycombinator.com/item?id=12567578

The counterpoint is 151M records represents .0000041% of global call records in 2016.

(Based on an estimate of 10B calls per day worldwide)

Take the time to understand the whole system you work within, not just your little stovepipe.

That system may not be technical, but procedural. It will include other business functions. It may include your customers. In any system, there is a clear "start" and "end" that encompasses a complete process and reason for being.

You'll find that in most organizations, people stay in their little corner, do their little thing, not caring much about what happens to the left and right of them. That leads to inefficiencies and missed opportunities.

If you understand the larger system, you'll be able to see opportunities others are blind to. Point a couple out and -if you're both respectful and right - it won't take folks long to think "man, this guy really gets it!"

To me, this principles of this style are best described in the Economist's Style Guide: http://www.economist.com/styleguide/introduction

"Clarity of writing usually follows clarity of thought. So think what you want to say, then say it as simply as possible."

"Pomposity and long-windedness tend to obscure meaning, or reveal the lack of it: strip them away in favour of plain words."

"Do your best to be lucid (“I see but one rule: to be clear”, Stendhal). Simple sentences help. Keep complicated constructions and gimmicks to a minimum"

"Long paragraphs, like long sentences, can confuse the reader. “The paragraph”, according to Fowler, “is essentially a unit of thought, not of length; it must be homogeneous in subject matter and sequential in treatment.”"

"Get: Get is an adaptable verb, but it has its limits. A man does not get sacked or promoted, he is sacked or promoted. Nor does a prize-winner get to shake hands with the president, or spend the money all at once; he gets the chance to, or is able to, or is allowed to.

The use case is right there in the text:

> enabling unmodified programs expecting a Unix-like environment to run directly in the browser

The latex example is probably the best example. There are a handful of latex typesetter web pages, but the "quick and dirty" implementation for all of them are something like:

(1) take the input (2) shell out to run the latex app on a unix box (3) return the output to the user via the browser

Step (2) requires a complete unix environment. As usage scales, so too does the processing power required. Imagine if that app got 10k requests/second: suddenly you have a farm of "rendering servers" and middleware managing availability, request routing, etc.

This allows you to offload step (2) to the user's browser for a broader range of applications, with easier/faster/less rewriting. While the upfront cost is still more complex if you have to port the app to this js platform, there may be long term savings in simplicity/efficiency from the reduced server requirements. e.g., you could reduce the latex typesetting webapp to static files served from S3.

Came to the comments looking for these links, too.

Results of my research are below; everything I found is anecdotal, consistent with the other comments. The most robust is the presentation at Velocity in 2009. [4, 5]

My notes:

Small ecommerce vendor, 2012. One second delay in page-load causes 7% loss in customer conversions. [1]

Marissa Meyer, 2006 Web 2.0 conference. Extra 1/2 second in page load time dropped traffic by 20%. [2]

Greg Linden, 2006 (same link as above) "We had similar experience at Amazon.com. We tried delaying page in increments of 100ms and found very small delays result in substantial and costly drops in revenue. [2]

Greg Linden, Make Data Useful, 2006 - Every 100ms delay costs 1% of sales. [3]

Velocity, 2009. The User and Business Impact of Server Delays, Additional Bytes, and HTTP Chunking in Web Search Presentation. Multiple observations. My net: Delays under 500m measurably impact customer satisfaction metrics, magnitude increases commensurately with delay. (Microsoft, Amazon, Google) [4, 5]

1 - https://info.ensighten.com/rs/ensighten/images/just-one-seco...

2 - http://glinden.blogspot.com/2006/11/marissa-mayer-at-web-20....

3 - http://www.gduchamp.com/media/StanfordDataMining.2006-11-28....

4 - http://radar.oreilly.com/2009/06/bing-and-google-agree-slow-...

5 - http://conferences.oreilly.com/velocity/velocity2009/public/...

THIS

This single diagram explains the market dynamic year over year in a way I've never seen anywhere else. The 1/3/5/10 yr returns figures you see don't even come close to understanding the nuances of one year over another.

I remember when this diagram was published in 2011 and _still_ refer to it routinely.

This is why you do dollar cost averaging and steadily invest every year, to spread out your investments over multiple years.

It's clear tech recruiting needs disrupting. We're still too dominated by traditional procedures that provide poor results. Folks with our background know in our guts this CTF-style thing has potential, we've just got to work out how to make it sustainable.

Would love to swap notes sometime. My wife is angling for an excuse to visit Chicago, but seeing as how winter's coming maybe y'all should visit Austin!

tptacek, patio11 and Erin -- I'm disappointed re: Starfighter, I was rooting for you.

I ran 0x41414141.com [1] for about 4 years. It was a set of CTF-style challenges of increasing difficulty with submissions via "secret" email addresses, a sendmail autoresponder and me - operating under the pseudo cavalier@0x41414141. It's singular goal was recruiting.

At the time, I was working with a totally badass team in a firm with a decidedly not-sexy brand for us security-types. We were hiring as fast as we could and _always_ had positions open. When we got someone good into the pipeline, we generally had no problem hiring them - the team and the work made that easy - but our candidate funnel was just too damn small. We had exhausted our referral pool, we were bringing on as many fresh grads as we could train, but it wasn't enough to keep up. We needed to broaden the funnel. Enter 0x41414141.com.

It was completely and totally unsupported, unrecognized and unreported through the official corporate recruiting channels. It was me, on my own time and my own dime with the quiet support of a few other guys in the shop. It had a singular purpose: to meet like-minded hackers and see if there was any chance they'd be interested in joining our merry little band of hackers.

Within the first year, I established the equivalent of a "repeatable sales process." There's the natural stages of the challenges themselves, but then the more delicate stages of transition:

(1) from the impersonal interaction with the service to the personal email exchange with cav,

(2) ...to a serious discussion about a new job

(3) ...to an IRL phone conversation

(4) ...to an open and honest talk about who we were, what we're doing and next steps

(5) ...to getting introduced to an actual corporate recruiter

Of course, like any "repeatable sales process" each stage is not only the continued progression but also qualification. The funnel was disappointingly ruthless, and that was just to get an intro to the recruiter. In any given year, I had:

(1) thousands of folks start challenges,

(2) several hundred make notable progress,

(3) traded personal email with dozens,

(4) got serious with 10s,

(5) interviewed a few,

(6) hired a couple

In the end, the results just didn't justify the effort.

To be clear - I loved running 0x41414141.com. I met a lot of great hackers and even hired a few. Many are HN'ers. (hi guys!) Many of the "security community rockstars" stumbled across the site and ran through the challenges as a fun exercise on a Sunday afternoon. I also watched - and coached - many clear newbs through the process, and was impressed with their grit, creativity and determination. I even hired a couple complete newbs, including a female, recent PoliSci grad working as a nanny who turned out to be an OUTSTANDING reverse engineer, when given the right support and environment to grow. She single-handedly kept my enthusiasm for running 0x41414141.com up for at least two years, even when the resulting hiring numbers made it clear it wasn't worth it.

I was really, really, really hoping Starfighter could "level up" the initial volume into that funnel, maintain (or improve!) the rough filtering percentages and have the resulting "hired" volume be higher and turn CTF recruiting into a sustainable business model. I'm disappointed it didn't work.

P.S. - this is the first time I've associated my real self with 0x41414141.com and the cavalier alter-ego. Congrats HN, you just got the scoop for this tiny little corner of history. While we're here...

  Hello Internet, this is cavalier.  If we connected
  via that moniker, please reach out and connect
  with my _real_ one. deets in my profile.  

1 - https://web.archive.org/web/20090204175328/http://0x41414141...

There is additional context in the Bloomberg article posted this morning. [1, 2]

Based on the timestamps, kinda looks like the Otto blogpost was prompted by the Bloomberg article -- even though the "agreements were reached" in July according to Bloomberg.

1 - https://news.ycombinator.com/item?id=12311559 2 - http://www.bloomberg.com/news/features/2016-08-18/uber-s-fir...

Please don't rewrite your network stack unless you can afford to dedicate a team to support it full time.

Twice in my career I have been on teams where we decided to rewrite IP or TCP stacks. The justifications were different each time, though never perf.

The projects were filled with lots of early confidence and successes. "So much faster" and "wow, my code is a lot simpler than the kernel equivalent, I am smart!" We shipped versions that worked, with high confidence and enthusiasm. It was fun. We were smart. We could rewrite core Internet protocol implementations and be better!

Then the bug reports started to roll in. Our clean implementations started to get cluttered with nuances in the spec we didn't appreciate. We wasted weeks chasing implementation bugs in other network stack that were defacto but undocumented parts of the internet's "real" spec. Accommodating these cluttered that pretty code further. Performance decreased.

In both cases, after about a year, we found ourselves wishing we had not rewritten the network stack. We started making plans to eliminate the dependency, now much more complicated because we had to transition active deployments away.

I have not made that mistake a 3d time.

If you are Google, Facebook or another internet behemoth that is optimizing for efficiently at scale and can afford to dedicate a team to the problem, do it. But if you are a startup trying to get a product off the ground, this is Premature optimization. Stay far, far away.

Thanks for the reply. I put cubism in the bucket of time series data, where the x-axis is time and the y-axis a single continuous scalar with definable magnitude. What makes these timeline views unique is multiple y-axis values, each with no magnitude, just metadata. (Or perhaps the metadata is more important than the magnitude)

Cubism is hawt for time series data, but there are lots of good options. It's a popular ask.

I've been doing a lazy search (i.e., passively watching) for a library like this with per-second resolution vs the per-month resolution in both timesheet.js and Chee Aun's Life.

Anyone have a recommendation?

+1 based on my own experience. I still don't grok The D3 Way, despite having used it several times in production projects.

I've taken the easy way out and used a D3 library a couple times and been disappointed by precisely what counchand refers to: changes that should be trivial resulting in notable implementation pain.

(but I like the looks of this - and kinda want to kick the tires and give it a shot!)

Most organizations, especially government, have a remarkable inability to man up, say "we fucked up" and take responsibility for their mistakes.

Reports like this emerge, in an attempt to obscure the truth with sheer volume.

ElasticSearch and Solr are both search engines built on top of Lucene. ElasticSearch just has all the hipster hype these days. Maybe update the description to include all three.

you consider that an appeal to authority? how about your complete disregard for his point.

thanks for re-enforcing my point.

HN, I'm ashamed of you.

The comments in this thread (and every other Snowden-related revelation in the last six months) have made it clear you are incapable of appreciating the magnitude and complexity of this scope of issue. The comment threads have been dominated by narrow, small minded thinking, bereft of any considered thoughtfulness. I quit reading your comments on these posts long ago, because they were a worthless echo chamber of self-righteous arrogance. I thought maybe, perhaps, this post would elicit better discussion. I should have known better.

Even after six months, I don't yet have a well-formed opinion on the topic. It's incredibly complicated and encompasses considerations most of us can barely comprehend. In an essay on the topic, Mike Hayden (ex USAF General, ex NSA director, ex CIA director) said: [1]

    it takes a special kind of arrogance for this
    young man to believe his moral judgment
    on the dilemma suddenly trumps that of two
    (incredibly different) presidents, both houses
    of the U.S. Congress, both political parties,
    the U.S. court system and more than 30,000 of
    his co-workers.

The HN collective deserves the same chastisement.

I expect more of HN than I do a typical forum. I dismiss the "not like the old days" cynics. Please don't prove them right.

1 - http://www.cnn.com/2013/07/19/opinion/hayden-snowden-impact/

If you liked this article, you should read Show Stopper. It's out of print, but there are ample used copies via Amazon.

http://www.amazon.com/gp/aw/d/0029356717/

People spend money to solve problems. If the problem you solve is not clearly defined, you cannot define your customers and cannot target your marketing.

The validation you need might be "that's cool!" The validation your company needs is "that solves my problem."

Looks like the Guardian got hacked. I clicked, saw the article header, but was then redirected to a NSFW ad for Teen Party Sluts.

Every USG veteran knows to be skeptical of mission briefs, regardless of important-looking classification markings.

That deck was put together by a mid- to low-level government program manager who owned the program. He is playing politics, making his program sound like the most awesome thing EVAR so he gets promoted. It's not an "official" document, despite all the fancy markings.

You cannot interpret every word as gospel.

Cute, but unlikely to be Snowden's job.

* The KRSOC is about 35 minutes outside Honolulu, far enough to not be "Honolulu" http://goo.gl/maps/R2vYe

* The position clearance requirements are just SECRET, NSA roles require TS/SCI + full scope poly

* There are lots of BAH jobs in Honolulu at PACAF and PACOM, amongst others.

* Positions of Snowden's type don't require 50% travel, those are more consistent with the PACOM and PACAF roles where you're supporting units throughout the Pacific.

All that said, these kinds of positions are a great way to go live in Hawaii for a few years. If you're young, single and want to live the island life for a while, it's a easy path.