Try to be curious and helpful without being arrogant.

Curious: when someone takes time to explain something to You, listen, even if You believe that You know already. Each new explanation may bring interesting details. Additionally listening is a way to be polite.

Helpful: When a teammate of Yours is struggling with a problem, take time to understand it and try to find a solution on your side, if You come with something that works (test to be sure), offer the solution: "look, I've got something interesting here, what do You think about it?"

The key here is be sincere and modest, especially when you're the youngest in the team, consider that for a senior it is not a very comfortable situation to be rescued by a rookie. Getting your help accepted is not always easy,

Free bonus: as time will come, You shall get a reputation of someone who can solve hard problems, those everyone else given up, You'll get opportunities to work on more interesting (and challenging) parts of projects and so on.

Good luck

I was talking about the report, not the summary.

I agree with Your analysis of the agenda.

Yet the report is wrong in the sense that it understates (intentionally?) value of being compliant.

Ironically the point of view of authors is a good illustration of Economics of Security http://en.wikipedia.org/wiki/Economics_of_security.

The word penalty isn't used even once in the document while compliance efforts are mainly driven by the need to avoid penalties because penalties are the main impact (otherwise there would be no need for regulations).

In figure 1 of the report one can read that consequences of custodial data leak would be cleanup and notification costs.

However here's an exerpt from a randomly picked PCI-DSS FAQ (http://pci.evolve-online.com/pci-faqs.asp)

"
What are the penalties for non-compliance?
In the event of a security breach, penalties for non-compliance are imposed. We understand currently these to be in the order of:

        * Fines at the rate of 5 euros per compromised account
        * A breach fee in excess of 100,000 euros per incident
        * Possible restrictions on the merchant
        * Permanent prohibition of the merchant's participation in Visa and MasterCard programs
        * Beyond compliance, business risks relative to brand, customer loyalty and company valuation exist if the cardholder data is not securely managed
"

Disclamer: I do PCI-DSS audits

... you need need a formal change management process with approval for security settings changes. And don't tell me that your shop is too small and you cant afford that. If you're too small stop doing IT. Now days IT issues have too much impact on people live to be done as a hobby. "We are too small" would not be enough of an excuse for a manufacturer for not doing safe cars/elevators/fridges/.... And that implies some sort of process and duty separation. IT is catching up the rest of the industry.

There are more that 200 requirements in PCI-DSS, performing 4 scans/year of your external IP addresses is just one of them.

... without the all-mighty SHELL

After conducting an audit of a Merchant et a PSP (payement service provider), a QSA (qualified security assesor) issues a ROC (report on compliance to PCI-DSS) that is submitted du issuers (VISA, Mastercard, Amex, JCB and Discover).

Then the issuers certify the auditee.

An individual can not be a QSA by itself, it has to work in an organization that is qualified as well. Among other things a QSA organization has to provision a HUGE amount of cash in case it is found liable of having unduly declared an auditee compliant.

When a breach occurs, there is an investigation and eventually it is found that the ROC was not accurate by the time of the audit in such case the QSA organization and the QSA individual are in trouble.

BTW a certification is only for one year.

Now the case is not about PCI-DSS but "Cardholder Information Security Program" (CISP) and the breach happened in 2005.
Therefore I think the outcome would not have much impact on PCI program where liabilities are well defined.

Most equipments systems and application have fancy features that allow to do elaborate things efficiently with less resources. This is an enjoyable part of our work, unfortunately it should be banned.

Restrain Yourself from the temptation to use those features.
Implement everything with the most basic and standard approach.

This may be frustrating, you may feel that you are wasting cash and time and sacrificing performance, but actually you'll get a more reliable and flexible system. And and outsider will be able to understand it more quickly.

Most systems allow to insert comments in the configuration. Use that extensively. The comments are the most immediate documentation and usually the most up to date.

One last hint: once your system is running and you have removed anything fancy from it leaving only the necessary complexity, take 15 minutes to describe the profile of the person that is eligible to manage it. Include books with the general knowledge that this person will need. Handle the description to your management.
This approach has following advantages:
- screening out totally unfit candidates
- helping the successor filling gaps in his knowledge
- avoiding to describe in your documentation common knowledge (in my experience this is 30-70% of the document and could be replaced with references to appropriate books)
- (free bonus) giving the management a better understanding of your own value

There are drawbacks as well:
- Going through books would take more to get a grasp than if you explain everything inline.

You can palliate by giving references to specific chapters. And stress on the fact that no one should be allowed to touch the systems *before* having the knowledge in the book. It's like driving the car: you should learn *before*, not *while* going to the highway.

"Only wimps use tape backup: _real_ men just upload their important stuff
on ftp, and let the rest of the world mirror it ;)"
                                                    Linus Torvalds Jul 20 1996, 3:00 am

When I discover a good book that is useful to me I always seek a way to reward the author, usually but buying the paper version. Kinda "magic spell" that is.

These two queuing disciplines allow you to create a fairly complete WAN simulator.
There are however few gotchas:

• Precise Bandwidth limitation at high speed required lots of CPU, powerful bus and quality network adapters (read: server class hardware)
• If you want to simulate a complex network and more than two nodes, you'll need IFB (or IMQ) in order to shape incoming traffic and yet some topologies would stay out of reach.
• Keep in mind that there are two types of latencies: the "serialization" latency that depends on packet size and link speed and "processing" latency that depends on packets rate and network hardware processing power. Netem simulates the "processing" one.
• Simulating "serialization" latency would be harder, require more CPU and as a "side" effect would also implement bandwidth limitation. As of today I'm not aware of any project that would accurately simulate "processing" latency in the Linux QoS framework.

All that being said in most cases having a rough simulation is sufficient to validate the behaviour of an application on WAN before deployment.
For those interested there is an excellent, 13years old but still relevant paper about latency: http://rescomp.stanford.edu/~cheshire/rants/Latency.html

This morning I had my son (4.5y) asking me to get him outside to ride his bicycle.
So I've asked him in turn to plan the whole thing: getting dressed, going to the place where the bicycle is stored, getting the key to open the door etc.

It was hard for him but he managed to have an "executive" plot.

So I think I'll do that little exercise again.

As a side note: would be interesting to conduct similar study on a representative population of executive officers and financial experts.

Hint for parents: to *always* explain why you want your kid to do such or such thing is a wrong path, they must know that there are circumstances (until certain age) that questioning parental authority is not allowed (and *that* could be explained: you are totally accountable on what they do and what happens to them).

If at your age you still have the ability and the will to undergo an academic cursus, it means you actually worth more than a youngster in terms of potential.

Now we have to convince the audience that FreeBSD, GNU/Linux etc are just browsers!

This is probably your last chance. I mean, it has not to be related to the reason you are leaving. But nobody's perfect, there is for sure something about you that was painful to your coworkers, recognize it, beg for pardon.