Securosis

Research

Cracking a 200 Year Old Cipher

I have a half dozen books on Thomas Jefferson’s life, but this is a pretty cool story I had never heard before. The Wall Street Journal this morning has a story about a Professor Robert Patterson, who had developed what appears to be a reasonably advanced cipher, and sent an enciphered message to President Jefferson in 1801. He provided Jefferson with the the message, the cipher, and hints as to how it worked, but it is assumed that Jefferson was never able to decrypt the message. The message was only recently decrypted by Dr. Lawren Smithline, a 36-year-old mathematician who works at the Center for Communications Research in Princeton, N.J., a division of the Institute for Defense Analyses. The key to the code consisted of a series of two-digit pairs. The first digit indicated the line number within a section, while the second was the number of letters added to the beginning of that row. For instance, if the key was 58, 71, 33, that meant that Mr. Patterson moved row five to the first line of a section and added eight random letters; then moved row seven to the second line and added one letter, and then moved row three to the third line and added three random letters. Mr. Patterson estimated that the potential combinations to solve the puzzle was “upwards of ninety millions of millions.” After about a week of working on the puzzle, the numerical key to Mr. Patterson’s cipher emerged – 13, 34, 57, 65, 22, 78, 49. Using that digital key, he was able to unfurl the cipher’s text: “In Congress, July Fourth, one thousand seven hundred and seventy six. A declaration by the Representatives of the United States of America in Congress assembled. When in the course of human events…” I am not sure why I am fascinated by this discovery. Perhaps it’s a bit like discovering hidden treasure. Share:

Share:
Read Post

Three Database Roles: Programmer, DBA, Architect

When I interview database candidates, I want to asses their skills in three different areas; how well they can set-up and maintain a database, how well they can program to a database, and how well they can design database systems. These coincide with the three roles I would typically hire: database administrator, database programmer and database architect. Even though I am hiring for just one of these roles, and I don’t expect any single candidate to be fully proficient in all three areas, I do want to understand the breadth of their exposure. It is an indicator of how much empathy they will have for their team members when working on database projects, and understand the sometimes competing challenges each faces. While there will always be some overlap, the divisions of responsibility are broken down as follows Database administrator – Installs, configures, manages the database installation. This will include access control, provisioning and patch management. Typically provide analysis into resource usage and performance. Database architect – Selects and designs the platforms, and designs or approves schema. It’s the architect’s responsibility to understand how data is used, processed and stored within the database. They typically select which database platform is appropriate, and will make judgment calls whether or not to use partitioning, replication, and other advanced features to support database applications. Database programmer – Responsible for coding the queries and use of the database infrastructure. Selection of data types and table design, and assists with We talk a lot about database security on this blog, but we should probably spend more time talking about the people who affect database security. In my experience database programmers are the least knowledgeable about the database, but have the greatest impact on database security and performance. I have been seeing a disturbing trend of development teams, especially web application programmers, who perform every function in the application and regard the database as a bucket where they dump stuff to save application state. This is reflected in the common choice of smaller, lighter databases that provide less functionality, and the use of abstraction techniques that clean up the object model but lose native functions that benefit performance, data integrity and security. Worse, they really don’t care the details of how it works as long as their database connection driver is reasonably reliable and the queries are easy to write. Why this is important, especially as it pertains to database security, is that you need to view security from these three perspectives and leverage these other practitioner skills within the organization. And if you have the luxury of being able to afford to employ all of these three disciplines, then by all means, have them cooperate in development, deployment and maintenance of database security. You architect is going to know where the critical data is and how it is moved through the system. Your DBA is going to understand how the databases are configured and what operations would be best moved into the database. If you are not already doing it, I highly recommend that you have your DBA’s and Architects do a sanity check on developer schema designs, review any application code that uses the database, and provide support to the development in team access control planning and data processing. It’s hard to willingly submit code for review, but better fix it prior to deployment than after. Share:

Share:
Read Post

Totally Transparent Research is the embodiment of how we work at Securosis. It’s our core operating philosophy, our research policy, and a specific process. We initially developed it to help maintain objectivity while producing licensed research, but its benefits extend to all aspects of our business.

Going beyond Open Source Research, and a far cry from the traditional syndicated research model, we think it’s the best way to produce independent, objective, quality research.

Here’s how it works:

  • Content is developed ‘live’ on the blog. Primary research is generally released in pieces, as a series of posts, so we can digest and integrate feedback, making the end results much stronger than traditional “ivory tower” research.
  • Comments are enabled for posts. All comments are kept except for spam, personal insults of a clearly inflammatory nature, and completely off-topic content that distracts from the discussion. We welcome comments critical of the work, even if somewhat insulting to the authors. Really.
  • Anyone can comment, and no registration is required. Vendors or consultants with a relevant product or offering must properly identify themselves. While their comments won’t be deleted, the writer/moderator will “call out”, identify, and possibly ridicule vendors who fail to do so.
  • Vendors considering licensing the content are welcome to provide feedback, but it must be posted in the comments - just like everyone else. There is no back channel influence on the research findings or posts.
    Analysts must reply to comments and defend the research position, or agree to modify the content.
  • At the end of the post series, the analyst compiles the posts into a paper, presentation, or other delivery vehicle. Public comments/input factors into the research, where appropriate.
  • If the research is distributed as a paper, significant commenters/contributors are acknowledged in the opening of the report. If they did not post their real names, handles used for comments are listed. Commenters do not retain any rights to the report, but their contributions will be recognized.
  • All primary research will be released under a Creative Commons license. The current license is Non-Commercial, Attribution. The analyst, at their discretion, may add a Derivative Works or Share Alike condition.
  • Securosis primary research does not discuss specific vendors or specific products/offerings, unless used to provide context, contrast or to make a point (which is very very rare).
    Although quotes from published primary research (and published primary research only) may be used in press releases, said quotes may never mention a specific vendor, even if the vendor is mentioned in the source report. Securosis must approve any quote to appear in any vendor marketing collateral.
  • Final primary research will be posted on the blog with open comments.
  • Research will be updated periodically to reflect market realities, based on the discretion of the primary analyst. Updated research will be dated and given a version number.
    For research that cannot be developed using this model, such as complex principles or models that are unsuited for a series of blog posts, the content will be chunked up and posted at or before release of the paper to solicit public feedback, and provide an open venue for comments and criticisms.
  • In rare cases Securosis may write papers outside of the primary research agenda, but only if the end result can be non-biased and valuable to the user community to supplement industry-wide efforts or advances. A “Radically Transparent Research” process will be followed in developing these papers, where absolutely all materials are public at all stages of development, including communications (email, call notes).
    Only the free primary research released on our site can be licensed. We will not accept licensing fees on research we charge users to access.
  • All licensed research will be clearly labeled with the licensees. No licensed research will be released without indicating the sources of licensing fees. Again, there will be no back channel influence. We’re open and transparent about our revenue sources.

In essence, we develop all of our research out in the open, and not only seek public comments, but keep those comments indefinitely as a record of the research creation process. If you believe we are biased or not doing our homework, you can call us out on it and it will be there in the record. Our philosophy involves cracking open the research process, and using our readers to eliminate bias and enhance the quality of the work.

On the back end, here’s how we handle this approach with licensees:

  • Licensees may propose paper topics. The topic may be accepted if it is consistent with the Securosis research agenda and goals, but only if it can be covered without bias and will be valuable to the end user community.
  • Analysts produce research according to their own research agendas, and may offer licensing under the same objectivity requirements.
  • The potential licensee will be provided an outline of our research positions and the potential research product so they can determine if it is likely to meet their objectives.
  • Once the licensee agrees, development of the primary research content begins, following the Totally Transparent Research process as outlined above. At this point, there is no money exchanged.
  • Upon completion of the paper, the licensee will receive a release candidate to determine whether the final result still meets their needs.
  • If the content does not meet their needs, the licensee is not required to pay, and the research will be released without licensing or with alternate licensees.
  • Licensees may host and reuse the content for the length of the license (typically one year). This includes placing the content behind a registration process, posting on white paper networks, or translation into other languages. The research will always be hosted at Securosis for free without registration.

Here is the language we currently place in our research project agreements:

Content will be created independently of LICENSEE with no obligations for payment. Once content is complete, LICENSEE will have a 3 day review period to determine if the content meets corporate objectives. If the content is unsuitable, LICENSEE will not be obligated for any payment and Securosis is free to distribute the whitepaper without branding or with alternate licensees, and will not complete any associated webcasts for the declining LICENSEE. Content licensing, webcasts and payment are contingent on the content being acceptable to LICENSEE. This maintains objectivity while limiting the risk to LICENSEE. Securosis maintains all rights to the content and to include Securosis branding in addition to any licensee branding.

Even this process itself is open to criticism. If you have questions or comments, you can email us or comment on the blog.