The 7 Simple Rules of Good Writing

The 7 simple rules of good writing from http://www.thehackeracademy.com/reporting-the-difference-between-good-and-great-penetration-testers/

1. Spell-check is mandatory. Even the first draft must pass spell-check before distributed.
2. Grammar-check is mandatory. It is not perfect but its better than 35% of writers.
3. use a consistent voice throughout the report.
4. Use a consistent tense throughout the report.
5. Use styles if writing in Word. This will enforce consistency and allow easy design changes throughout the document.
6. Appearance matters. Focus on margins, headers, footers and tables to ensure neatness.
7. Once the first draft is done, turn on track changes and leave it on until the release candidate.

Remember that writing is thinking on paper (or keyboards).

Writing is Rewriting:

• Read each sentence in the document. For each, ask the following questions:

1. Does this sentence add to the information in the document?
2. Does this sentence add to the reader's understanding of the information in the document?
3. For each word in the sentence, ask: Would the sentence have the same meaning without this word? If yes, remove the word.

Reporting: the key for good penetration testing

The hacker academy has a wonderful article about Reporting, which can be found at http://www.thehackeracademy.com/reporting-the-difference-between-good-and-great-penetration-testers/

Here are some key points from the webcast:

• The Executive Summary (It should be understood by your mom or your wife)

1. What did we do?
2. Why did we do it?
3. What did we find?
4. How bad is it?
5. How much needs to be done to fix it?
6. How good will we be afterwards?

• The Findings Summary (Designed to be read by the CIO / CISO / Director-level security executives. More details than the executive summary)

1. What is the severity distribution of the findings?
2. What are the strengths?
3. What are the weakness?
4. How do we compare to last year / last time?

(For example, we can have a overall strength or overall weakness sections. A chart of comparison with last result is very helpful )

• The technical details (the questions to answer)

1. How did we perform the penetration test?
2. What specifically did we find?
3. How can our findings be reproduced?
4. What needs to be done to fix each finding?

(Present great information with diagram. Avoid too much details. )

• Design is important (Convert your information more effectively)

This is a very interesting article,

Can You Train A Great Penetration Tester?

The hacker mindset can't be taught -- it must be developed and refined over time

According to the author, there are different types of penetration testers:

• Novice level. They know the fundamentals of security, the attack methodology, and the testing techniques. There is marginal skill improvement with additional experience.
• Advanced level. This requires study, especially, self-study. Focused and continuous learning is essential in being effective as a pen tester. It requires passion, learning and training.
• Expert level. It can not be trained. They possess "hacker mindset", which can not be taught. It must be developed and refined over the years. Two key talents: the ability to synthesize disparate data to create actionable information and the knack for identifying and pursuing the most effective attack path against a target.
• Master levels. They have one secret that sets them apart from everyone else....

SSL/TLS Deployment Best Practices guide from ssllabs.com

The latest SSL/TLS deployment best practices guide from ssllabs.com is ready at

https://www.ssllabs.com/downloads/SSL_TLS_Deployment_Best_Practices_1.0.pdf

Here are some key points:

• Use 2048-bit private keys and protect private keys
• Obtain certificates from a reliable CA
• Use only secure protocols (SSLv3 and TLS 1.0 at least) and secure cipher suites
• Disable client-initiated renegotiation
• Mitigate known problems (Disable insecure negotiation and prioritize RC4 to mitigate the BEAST attack)
• Use persistent connections (HTTP)
• Encrypt 100% of your web site traffic
• Ensure that cookies are secured
• Ensure that mixed content is not used
• Enable HTTP Strict Transport Security
• Understand and acknowledge third-party trust

Five principles for meaningful meetings

I came across this post, http://www.codinghorror.com/blog/2012/02/meetings-where-work-goes-to-die.html. The author presented five good principles for successful meetings:

1. No meeting should ever be more than an hour, under penalty of death.
   

   The first and most important constraint on any meeting is the most precious imaginable resource at any company: time. If you can't fit your meeting in about an hour, there is something deeply wrong with it, and you should fix that first. Either it involves too many people, the scope of the meeting is too broad, or there's a general lack of focus necessary to keep the meeting on track. I challenge anyone to remember anythingthat happens in a multi-hour meeting. When all else fails, please keep it short!

2. Every meeting should have a clearly defined mission statement.
   

   What's the mission statement of your meeting? Can you define the purpose of your meeting in a single succinct sentence? I hesitate to recommend having an "agenda" and "agenda items" because the word agenda implies a giant, tedious bulleted list of things to cover. Just make sure the purpose of the meeting is clear to everyone; the rest will take care of itself.

3. Do your homework before the meeting.
   

   Since your meeting has a clearly defined mission statement, everyone attending the meeting knows in advance what they need to talk about and share, and has it ready to go before they walk into the room.Right? That's how we can keep the meeting down to an hour. If you haven't done your homework, you shouldn't be in the meeting. If nobody has done their homework, the meeting should be cancelled.

4. Make it optional.
   

   "Mandatory" meetings are a cop-out. Everyone in the meeting should be there because they want to be there, or they need to be there. One sure way to keep yourself accountable for a meeting is to make everyone optional. Imagine holding a meeting that people actually wanted to attend, because it was … useful. Or interesting. Or entertaining. Now make it happen!

5. Summarize to-dos at the end of the meeting.
   

   If your meeting never happened, what would the consequences be? If the honest answer to that is almost nothing, then perhaps your meeting has no reason to exist. Any truly productive meeting causes stuff to happen as a direct result of the decisions made in that meeting. You, as a responsible meeting participant, are responsible for keeping track of what you need to do – and everyone in the room can prove it by summarizing their to-do list for everyone's benefit before they leave the meeting.

However, it is very difficult for number 3 and number 4 to happen in real time. It is too often for some guys showing up at the meeting without bothering to read agenda or do their homework at all. At the same time, there are lots of meetings that you need to have certain people from certain areas to show up, otherwise, nothing can be achieved. In some companies, if meetings are made "optional", people might choose to skip them. The key for the successes of meetings are tied with company culture, which is another tough topic.

Let the meetings begin.

CVE-2012-0053

According to http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-0053, protocol.c in the Apache HTTP Server 2.2.x through 2.2.21 does not properly restrict header information during construction of Bad Request (aka 400) error documents, which allows remote attackers to obtain the values of HTTPOnly cookies via vectors involving a (1) long or (2) malformed header in conjunction with crafted web script.

Here is the exploit script from http://downloads.securityfocus.com/vulnerabilities/exploits/51706.js

In this experiment, Apache/2.2.21 windows version was tested. The popular open source project phpMyAdmin was deployed as part of XAMPP.

As shown in this screencopy, the application set three httponly cookies: phpMyAdmin, pma_lang, pma_collation_connection.

Once the exploit script is run, the request contains a couple of generated cookies like this screen copy. 

Since the total length of cookie header exceeds the server limit. This request generated a 400 error on the server. But the response from the server contained those three HttpOnly cookies. This test showed that the server is vulnerable to this security issue.