params.json

{
  "name": "The Octopus Platform",
  "tagline": "A Code Intelligence System",
  "body": "The Octopus project deals with the development of a Code Intelligence System. The system continuously accumulates security relevant\r\ninformation about program code used within an organization, makes it\r\naccessible to both analysts and tools, and employs pattern recognition\r\ntechniques to recommend code that contains flaws with high\r\nprobability. Built with emerging \"big data\" components under the hood,\r\nthe resulting code analysis platform is designed to handle\r\ndistributions worth of code. This is a requirement for the approach as\r\nstatistical methods cannot function correctly without large amounts of\r\ndata at their disposal. We additionally make an effort to provide\r\nclean interfaces to extend the platform, to enable research on new\r\nmethods for code analysis, and adaption to the unique requirements of\r\nthe programs under inspection.\r\n\r\n## Background\r\n\r\nTo date, security systems focus mainly on the detection of known\r\nvulnerabilities, attacks, and malicious code. With attackers in mind\r\nwho concentrate on compromising a large number of hosts with minimum\r\neffort, and no particular target in mind, these strategies seem\r\nreasonable.\r\n\r\nOn the other end of the spectrum, organizations may be targeted by\r\nattackers willing to invest time and resources to compromise that\r\norganization's network in particular, or even the devices of one\r\nspecific individual. While realistically speaking, an attacker\r\ninvesting above a certain threshold will succeed, it is worth asking\r\nwhether we can find a middle ground between protecting against known\r\nvulnerabilities only, and auditing for vulnerabilities day and night.\r\n\r\nIn essence, it must be hard to identify new vulnerabilities in the\r\nprograms we deploy because flaws that are obvious no longer exist. An\r\nattacker should be unable to identify a previously unknown\r\nvulnerability simply by finding a variation of a known flaw, or by\r\nscanning for vulnerabilities very typical for the type of application\r\nor the libraries it uses.\r\n\r\nThis is not trivial. Today, successful identification of even simple\r\nvulnerabilities and assessing of exploitability are tasks that\r\nincreasingly require a deep understanding of program\r\nspecifics. Experienced vulnerability researchers therefore suggest to\r\nreview both the program-specific APIs for quirks, as well as the\r\nsecurity history for common programming patterns that caused\r\nvulnerabilities (see, for example, Chris Rohlf's BlackHat training on\r\nvulnerability discovery (https://github.com/struct/mms) and Dowd et\r\nal.'s \"The Art of Software Security Assessment\".)\r\n\r\nIt is therefore not uncommon today to see articles about vulnerability\r\ndiscovery and exploitation that focus entirely on the\r\nsecurity-relevant internals of a specific program (see Ilja van\r\nSprundel's work on Windows device drivers, argp's work on Firefox, or\r\nhuku's work on Flash). Knowledge of this kind is acquired in an often\r\npainful research process that uncovers information limited in value to\r\na particular program, but absolutely required to identify relevant\r\nvulnerabilities in it. This information is publicly available to\r\nattackers and defenders alike and provides a starting point for\r\nanalysis.\r\n\r\n## A Code Intelligence System\r\nTo date, there is no system to concentrate what we know about the\r\ntypical vulnerabilities associated with programs, their libraries, and\r\nprogramming languages. Moreover, there are no mechanisms to preserve\r\nand share this information for other analysts to avoid flaws in the\r\nfuture. Finally, no way of automatically exploiting this information\r\nprogrammatically exists, that is, to build tools for semi-automated\r\nvulnerability assessment that leverage this information.\r\n\r\nThe long-term objective of the Octopus project is to develop a novel\r\ntype of security component: a code intelligence system. The\r\nsystem keeps track of the program code developed or used by an\r\norganization, along with its development history, and in particular,\r\nsecurity patches, as well as knowledge about vulnerable programming\r\npatterns accumulated over the past. With this information at hand, it\r\nrepeatedly mines programs for code that seems worth auditing, along\r\nwith useful hints on the difficulties associated with the use of the\r\nemployed APIs. As such, it provides a central point for code analysts\r\nto share their knowledge, and to extract it for use in their tools.\r\n\r\n",
  "note": "Don't delete this file! It's used internally to help with page regeneration."
}