Many marketers consider white papers the leading tool for influencing buyers, and yet they are difficult and expensive to create and sometimes fail to capture buyer attention. If you want a successful white paper, I offer these thoughts on what you SHOULDN’T do. If you don’t believe me, do some testing.
​
Without further adieu, top reasons white papers fail:

1. Your paper fails to deliver value. It is too salesy. It lacks substance, is poorly written, or is inaccurate. This is the Number 1 complaint I hear and quite honestly it makes people angry. The reader considers the white paper a contract: they give you their attention to read it and you deliver some sort of value in the form of knowledge. If you don’t deliver as expected, they are unlikely to do business with you and unlikely to download your future papers. Nobody likes to be tricked into wasting their time as a sales target.
2. You make it too difficult to obtain the paper. (a) You require too much information to register. The more information you require on your registration form, the less likely people are to complete the transaction. Name and email address are all that are truly required. People are going to drop off when you start requiring telephone number, place of employment, etc. (b) You block gmail and other free email domains. I saw this the other day on a webinar registration form for Amy Porterfield who supports course entrepreneurs, and I was baffled that someone with that audience would block gmail addresses. Legitimate buyers sometimes use free email domains. For instance, sometimes a buyer will need to research a purchase but is not authorized to represent the organization. Also, sometimes in these days of spam and malware, a legitimate buyer prefers not to put their company email at risk. Do you really want to turn them away at the door? By the way, if the goal is to prevent spam registration, consider adding a CAPTCHA test to detect a human or add a custom profile question such as “Are you a robot?”
3. Your paper's title is too long.  Literally, the shorter the title, the better it generally performs, assuming it is still descriptive. Try questions and active language. Focus on outcome. If you have too much information, put it into a subhead. Paper title is an easy candidate for A/B testing.
4. You are talking to the wrong audience. If you are targeting the C suite, you need to talk about business problems instead of technology problems. If you are targeting technical folks, you better be air tight on technical facts. You can sometimes appeal to both audiences by having a business-oriented introduction and conclusion (for those who flip to the end) and a well written technical section in the middle. If you play it well, the tech audience will hand your paper up and the managers will hand your paper down.
5. You don’t have the social media or sales maturity to adequately distribute and promote the piece.  
6. This is your first and only white paper. If so, people are not used to looking to you for thought leadership. Try producing a couple more and also produce several related blog pieces per paper to boost traffic and build authority.
7. Your paper lacks visual appeal. Try adding an infographic. See if icons are effective for you; some people say the use of icons is on its way out, but iconography is currently alive and well so consider it. Also, while many in marketing look down upon stock photography, testing shows that people still respond to a person looking directly into the camera so test that with your audience too. Testing eliminates the need for guessing. Get to know your audience and do what works.
8. There is no apparent call to action or next step. Ideally, you should include a call to action to move the reader deeper into the sales cycle, from awareness to prospect to client. A call to action can prompt the reader to get the next white paper, webinar, or resource such as templates, for instance. I prefer to put the call on a page following the conclusion, so the ask is separate from the valued content. You can get away with a weak or missing call to action if your main distribution channel is your sales force, because they will naturally follow up and escort the prospect to the next step.
9. You chose the wrong writer or failed to provide your writer with the right support. The writer must be someone who isn’t afraid to get in the weeds with independent research and a technical collaborator to create quality content. Don’t assume that someone who can write blog posts can also write white papers. Likewise, a white paper editor may be a willing writer but lacking in some skills. Sure, give your resource a chance but provide a coach or have a better-suited resource on call in case things don't work out.
10. Reader’s choice. What would you add?

 
About Ann

Ann Grove is often Logical’s lead consultant. She is known for producing security and compliance white papers that resonate with the C suite.  In January 2019, Ann started a Facebook group, White Paper Mastery, for white paper enthusiasts. 

By Ann Grove, Logical's President 

Although some developers see threat modeling as a low-value, high-effort exercise, the process provides a helpful, holistic view to find, identify, and evaluate risks that wouldn't otherwise be recognized.

​That was the contention of John Misczak (@johnmisczak) at an OWASP Philly (@phillyowasp) event Friday. Misczak is a senior consultant at Security Risk Advisors, a security and compliance services and products company. The day's theme was web application security in agile environments. (See the next blog post to learn about better integrating the security team into the development team.)

Misczak said that a good threat model picks up problems that are not identified by other security assessments such as penetration tests (pen tests).

Let's look at the top five of the Misczak Top 10 areas that a threat model should address: 

1. Threats introduced if the application or technology being modeled employs jump host architecture. A jump host is a computer used to manage devices in a separate security zone such as a trusted computer managing a host in a DMZ. Misczak provided the example of a company that pulls in blog content from a static service.  
2. Threats introduced through the use of third-party code libraries. Misczak talked about a real-life case where a library of thousands of libraries were taken offline due to an infringement dispute. While I couldn't find that news story, the risk is clear since third-party library components comprise up to 90 percent of applications. (As a side note, Larry Maccherone (@lmaccherone) from Comcast recently presented at the Philly Security Shell and in part discussed the effectiveness of securing library components with Software Composition Analysis.) 
3. Threats introduced by weak key management. Misczak provided the example of two systems reconciled through a flat file when the key on one side is weak. Organizations should also consider where keys are stored, how file and directory permissions are managed, how keys are rotated, whether the key is on the same server or is pulled from elsewhere at the moment is needed for encryption or decryption. 
4. Threats introduced by rate limiting. According to Misczak, organizations may wish to consider NOT locking out users who with a minute or two make a couple of password reset attempts (which generate a code sent to the user via email or by text). The organization may wish to only throttle against automated attacks that generate hundreds of attempts per minute, Misczak  said. 
5. Threats introduced by service accounts. Primarily, Misczak pointed to risk from the reuse of service accounts for multiple applications and services. He also mentioned that regular maintenance is required: passwords need to be updated and service accounts should be rotated.

I have helped prepare threat model reports for a security consultancy client and the results were presented much like the results of a pen test with a list of findings (security weaknesses), and, for each finding, the assets impacted, a risk rating, a description of the problem, and recommendations. Therefore, I asked Misczak if organizations track and resolve threat model findings using the same methods applied for pen test findings. Misczak said many organizations do not track pen test findings to closure, and so should use a different approach to ensure that all threat model findings are fully addressed.

For those interested in threat modeling, Misczak recommended checking out a new, open-source OWASP threat modeling tool, Threat Dragon. Available for Windows, Mac, Linux (soon), or via web app, the tool includes system diagramming and a powerful rule engine to auto-generate threats/mitigations.

About the Author

​Ann Grove, president of Logical, is a chapter leader for OWASP's Baltimore Chapter.

Employ Security by Design with Static Analysis

A static analysis tool is a debugging tool that examines code for known issues without executing an application. Typically, static analysis is run on a designated frequency such as weekly or monthly.

To implement static analysis, Lackey recommends beginning with classes of vulnerability that are the easiest to address. This also demonstrates to the organization that static analysis can deliver both value and velocity. The analysis tool should be “tuned” for each class to eliminate most false positives before moving onto the next class, Lackey says, rather than attempting to tune all classes at once. For instance, a team can start with command execution and later move on to XSS, SQLi, Directory Traversal, etc.

In addition, rather than instituting automatic blocking to prevent disallowed primitives, Lackey recommends talking to developers. Through conversation, the security team can learn what a developer is attempting to protect and discuss how that can best be accomplished through hashing, encryption, file system operations, or another method. 
Finally, Lackey recommends building proactive alerting so that leaders are advised when sensitive or rarely changed portions of the codebase are modified. He suggests alerting development and security engineers to changes to key platform protections, rather than blocking so that approvals are not needed during an emergency. For instance, a team can establish an alert for a hash change on key files, authorization of primitives, session management, encryption wrappers, etc. This provides accountability without impacting velocity. 

Provide Continuous Feedback with Penetration Testing and Bug Bounties

Lackey discussed two primary sources of security visibility: penetration tests and bug bounty programs. 

Penetration testing (pen testing) was “real-time enough when software was released every 18 months,” Lackey said. The purpose of pen testing in organizations with bounties has shifted; the value of pen tests now is that they are more directed.

Many organizations augment pen tests these days with bug bounty programs which provide truly real-time and continuous feedback. Through bounty programs, organizations compensate or reward external volunteer testers for finding weaknesses or bugs in the product being tested. The emergence of bounty platforms such as HackerOne and Bugcrowd make bounty programs more manageable, for instance for international payments, Lackey said.

Increase Security Visibility 

To increase security visibility, Lackey recommends developing capabilities to detect attacks as early as possible in the attack chain. This is especially important when a bounty program is planned, in case a bounty hunter discovers a bug that he or she decides not to report, Lackey said. The hunter could decide to sell the bug to hackers or use the bug for a live exploit later. 

In addition, organizations should continuously test and refine their vulnerability and incident response processes and mature their forensic capabilities.

Conclusion

Organizations realize it is no longer feasible for security teams to primarily focus efforts late in development when discovered bugs are costly and may delay scheduled releases. Security teams in agile environments are increasingly participating in the early phases of web application development and are collaborating with, educating, and empowering developers. Even in fast-paced agile environments, secure development is possible with techniques such as integrating security into design, providing continuous security feedback, and making security visible, Lackey said.​

About Ann
Ann Grove is a Certified Information Privacy Professional and security enthusiast with 15+ years of writing experience.

By Ann Grove, Logical's President

So you've hired a consultant or agency to develop a marketing deliverable such as a blog post, white paper, or video. Now is not the time to wash your hands of the project. Instead, increase the effectiveness of the content and improve the outcome by providing your consultant with some key documents you likely already have on hand if you have a marketing team: 

• Buyer personas, so the consultant understands the audience
• Keywords that a potential customer would use to search for the organization or the topic of the content, so those words can be used in the piece
• A list of specific targeted industry verticals
• Content examples (yours or a competitor's) that got a strong response from the intended audience
• Any style guide or logo-usage guidelines

Your marketing consultant also need at least one more resource: a Subject Matter Expert (SME) or collaborator. Occasionally we meet a client who wants the Logical writer to develop content with minimal direction and no team interaction, but a technical review is still required. 

Our most successful projects are typically those where the client takes the time to discuss things like market trends, industry news, and product differentiation. The client's deep industry knowledge enhances our keyword-optimized and targeted content, resulting in high-performing results.

About Ann

​Ann has passion for producing content that people rely on for buying decisions. She takes all of the stress out of outsourcing security content and compliance analysis with no-obligation consultations. Reach Logical today using our Contact page.

​By Ann Grove, Logical's President

It's all about momentum. That's why sometimes a Big Hairy Audacious Goal (BHAG) is achieved when a Small Hairless Modest Goal remains unfinished.

At Logical, our BHAG is to help secure the world through content for enterprise leaders that inspires action. What is your BHAG?