5 research outputs found
Recommended from our members
The Effectiveness of Software Diversity
This research exploits a collection of more than 2,500,000 programs, written to over 1,500 specifications (problems), the Online Judge programming competition. This website invites people all over the world to submit programs to these specifications, and automatically checks them against a benchmark. The submitter receives feedback, the most frequent responses being "Correct" and "Wrong Answer".
This enormous collection of programs gives the opportunity to test common assumptions in software reliability engineering about software diversity, with a high confidence level and across several problem domains. The previous research has used collections of up to several dozens of programs for only one problem, which is large enough for exploratory insights, but not for statistical relevance.
For this research, a test harness was developed which automatically extracts, compiles, runs and checks the programs with a benchmark. For most problems, this benchmark consists of 2,500 or 10,000 demands. The demands are random, or cover the entirety or a contiguous section of the demand space.
For every program the test harness calculates: (1) The output for every demand in the benchmark. (2) The failure set, i.e. the demands for which the program fails. (3) The internal software metrics: Lines of Code, Halstead Volume, and McCabe's Cyclomatic Complexity. (4) The dependability metrics: number of faults and probability of failure on demand.
The only manual intervention in the above is the selection of a correct program. The test harness calculates the following for every problem: (1) Various characteristics: the number of programs submitted to the problem, the number of authors submitting, the number of correct programs in the first attempt, the average number of attempts until a correct solution is reached, etc. (2) The grouping of programs in equivalence classes, i.e. groups' of programs with the same failure set. (3) The difficulty function for the problem, i.e. the average probability of failure of the program for different demands. (4) The gain of multipleversion software diversity in a 1-out-of-2 pair as a function of the pfd of the set of programs. (5) The additional gain of language diversity in the pair. (6) Correlations between internal metrics, and between internal metrics and dependability metrics.
This research confirms many of the insights gained from earlier studies: (1) Software diversity is an effective means to increase the probability of failure on demand of a 1-out-of- 2 system. It decreases the probability of undetected failure on demand by on average around two orders of magnitude for reliable programs. (2) For unreliable programs the failure behaviour appears to be close to statistically independent. (3) Run-time checks reduce the probability of failure. However, the gain of run-time checks is much lower and far less consistent than that of multiple-version software diversity, i.e. it is fairly random whether a run-time check matches the faults actually made in programs. (4) Language diversity in a diverse pair provides an additional gain in the probability of undetected failure on demand, but this gain is not very high when choosing from the programming languages C, C++ and Pascal. (5) There is a very strong correlation between the internal software metrics.
The programs in the Online Judge do not behave according to some common assumptions: (1) For a given specification, there is no correlation between selected internal software metrics (Lines of Code, Halstead Volume and McCabe's Cyclomatic Complexity) and dependability metrics (pfd and Number of Faults) of the programs implementing it. This result could imply that for improving dependability, it is not effective to require programmers to write programs within given bounds for these internal software metrics. (2) Run-time checks are still effective for reliable programs. Often, programmers remove runtIme checks at the end of the development process, probably because the program is then deemed to be correct. However, the benefit of run-time checks does not correlate with pfd, i.e. they. are as effective for reliable as for unreliable programs. They are also shown to have a negliigible adverse impact on the program's dependability
Diversity management in intrusion tolerant systems
Tese de mestrado em Informática, apresentada à Universidade de Lisboa, através da Faculdade de Ciências, 2011Uma aplicação importante dos protocolos de tolerância a faltas arbitrárias (ou Bizantinas) é a construção de sistemas tolerantes a intrusões, que são capazes de funcionar correctamente mesmo que alguns dos seus componentes sejam comprometidos. Estes sistemas são concretizados através da replicação de componentes e da utilização de protocolos capazes de tolerar faltas arbitrárias, quer na rede como num subconjunto de réplicas.
Os protocolos garantem um comportamento correcto ainda que exista uma minoria (normalmente menor do que um terço) de componentes controlados por um adversário malicioso.
Para cumprir esta condição os componentes do sistema têm de apresentar independência nas falhas. No entanto, quando estamos no contexto da segurança de sistemas, temos de admitir a possibilidade de ocorrerem ataques simultâneos contra várias réplicas.
Se os vários componentes tiverem as mesmas vulnerabilidades, então podem ser comprometidos com um só ataque, o que destrói o propósito de se construir sistemas tolerantesa intrusões. Com o objectivo de reduzir a probabilidade de existirem vulnerabilidades comuns pretendemos utilizar diversidade: cada componente usa software distinto que fornece as mesmas funcionalidades, com a expectativa de que as diferenças vão reduzir o número de vulnerabilidades semelhantes.
Reconhecemos também que isoladamente a tolerância a faltas arbitrárias tem algumas
limitações uma vez que consideramos faltas maliciosas: uma das limitações mais importantes é que dado tempo suficiente o adversário pode comprometer f + 1 réplicas, e então violar a hipótese de que no máximo f componentes podem sofrer uma falta, levando os recursos do sistema à exaustão.
Uma forma de lidar com esta limitação consiste em renovar periodicamente as réplicas, uma técnica denominada por Recuperação Proactiva. O propósito das recuperações é limpar o estado do sistema, reiniciando a replica com código disponível em armazenamento apenas com permissões de leitura (ex: CD-ROM) e validar/obter o estado de outro componente (que seja correcto). Num sistema tolerante a intrusões com recuperação proactiva o intervalo temporal que o adversário tem para comprometer f + 1 réplicas passa a ser uma pequena janela de vulnerabilidade, que compreende o tempo de recuperação do sistema todo. Apesar dos benefícios que as recuperações periódicas oferecem em termos de fiabilidade persiste a seguinte dificuldade: as vulnerabilidades exploradas nas execuções anteriores da replica podem ainda ser exploradas depois da recuperação. Esta limitação permite facilmente a um atacante criar um script que automaticamente compromete novamente a replica logo a seguir à sua recuperação pois as vulnerabilidades não são apagadas mas sim a falta (i.e., o estado incorrecto no componente devido à intrusão).
Com o objectivo de melhorar o sistema introduzimos diversidade nas recuperações, mais precisamente em componentes off-the-shelf (OTS). Hoje em dia praticamente todo o software desenvolvido é baseado neste tipo de componentes, como por exemplo sistemas operativos (SO) e gestores de bases de dados. Isto deve-se principalmente à complexidade do desenvolvimento destes componentes em conjugação com os benefícios relacionados com o baixo custo, a instalação rápida e a variedade de opções disponíveis. No entanto, a maior parte dos componentes OTS não foram desenhados com segurança como prioridade, o que significa que em todos eles existem vulnerabilidades que podem ser maliciosamente exploradas.
Por vezes, sistemas supostamente seguros são comprometidos através de uma componente critica na sua infraestrutura. Por outro lado, dada a quantidade de oferta das componentes OTS, utilizar diversidade nestes componentes é menos complexo e tem um menor custo do que desenvolver várias componentes de software diferentes. Um bom exemplo disto é o caso dos SO: as organizações na verdade preferem um sistema operativo OTS do que construir o seu próprio SO. Dada a variedade de sistemas operativos disponíveis e a criticidade do papel desempenhado por estes em qualquer computador, a diversidade ao nível dos SO pode ser uma forma razoável de garantir segurança contra vulnerabilidades comuns com um baixo custo adicional.
O foco nas vulnerabilidades comuns é um aspecto importante deste trabalho. Visto que a tolerância intrusões ´e aplicada em sistemas críticos, ´e seguro afirmar que no sistema operativo vai ser assegurada a máxima segurança, aplicando todos os patches disponíveis.
No entanto, mesmo com sistemas actualizados, o sistema pode ser comprometido através de vulnerabilidades que ainda não foram descobertas pelos programadores (vulnerabilidades de dia zero), visto que os patches aparecem normalmente depois da vulnerabilidade ser anunciada. Se uma vulnerabilidade de dia zero afectar o sistema existe uma janela de oportunidade para o atacante causar uma intrusão.
A questão principal que tratamos na primeira parte desta tese é: Quais são os ganhos de se aplicar diversidade de SO num sistema tolerante a intrusões replicado? Para responder a esta questão, recolhemos e selecionámos dados sobre vulnerabilidades do
NIST National Vulnerability Database (NVD) entre 1994 e 2010 para 11 sistemas operativos.
Os dados do NVD relativamente aos SO são consideráveis, o que nos permite tirar algumas conclusões. Cada vulnerabilidade presente no NVD contém (entre outras coisas) informação sobre que produtos são afectados pela vulnerabilidade. Recolhemos estes dados e verificámos quantas vulnerabilidades afectam mais do que um sistema operativo.
Constatámos que este número é relativamente pequeno para a maior parte de de sistemas operativos. Este estudo foi depois estendido a um número maior de SO, com conclusões semelhantes para esses conjuntos. Estes resultados sugerem que existem ganhos de segurança que podem ser alcançados recorrendo à utilização de sistemas operativos diferentes num sistema replicado.
Como nota de cautela, não pretendemos afirmar que estes resultados são uma prova final sobre a ausência de vulnerabilidades comuns (embora sejam bastante promissores).
Um dos principais problemas encontrados é que os relatórios focam-se nas vulnerabilidades e não em quantas intrusões ou exploits ocorreram para cada vulnerabilidade; isto faz com que a avaliação, em termos de segurança, seja mais difícil.
A segunda parte da tese propõe uma arquitectura que explora a diversidade disponível
nos sistemas operativos juntamente com mecanismos de recuperação proactiva. O objectivo principal é mudar a configuração das réplicas de forma a alterar o conjunto de vulnerabilidades após uma recuperação. Desenvolvemos também um algoritmo que seleciona entre os candidatos o melhor sistema operativo para ser usado numa recuperação, assegurando o maior nível de diversidade possível entre as réplicas que se encontram em execução.One of the key benefits of using intrusion-tolerant systems is the possibility of ensuring
correct behavior in the presence of attacks and intrusions. These security gains are
directly dependent on the components exhibiting failure diversity. To what extent failure
diversity is observed in practical deployment depends on how diverse are the components
that constitute the system. In this thesis we present a study with operating systems (OS)
vulnerability reports from the NIST National Vulnerability Database. We have analyzed
the vulnerabilities of 11 different OS over a period of roughly 15 years, to check how
many of these vulnerabilities occur in more than one OS. We found this number to be
low for several combinations of OS. Hence, our analysis provides a strong indication that
building a system with diverse OS may be a useful technique to improve its intrusion
tolerance capabilities. However, even with diversity the attacker eventually will find vulnerabilities
in all OS replicas. To mitigate/eliminate this problem we introduce diverse
proactive recovery on the replicas. Proactive recovery is a technique that periodically rejuvenates
the components of a replicated system. When used in the context of intrusiontolerant
systems, in which faulty replicas may be under control of some malicious user,
it allows the removal of intrusions from the compromised replicas. We propose that after
each recovery a replica starts to run a different software. The selection of the new
replica configuration is a non-trivial problem, as we will explain, since we would like to
maximize the diversity of the system under the constraint of the available configurations
Management: A bibliography for NASA Managers
This bibliography lists 707 reports, articles and other documents introduced into the NASA scientific and technology information system in 1985. Items are selected and grouped according to their usefulness to the manager as manager. Citations are grouped into ten subject categories: human factors and personnel issues; management theory and techniques; industrial management and manufacturing; robotics and expert systems; computers and information management; research and development; economics, costs, and markets; logistics and operations management; reliability and quality control; and legality, legislation, and policy
Future Coal Supply for the World Energy Balance; Proceedings of the Third IIASA Conference on Energy Resources, November 28 - December 2, 1977
There is growing concern and interest in the re-emergence into the energy picture of "King Coal." Coal, as it is produced today and, still more, as it will be produced tomorrow and in the next century, has many new features. Reserves and resources are revised upward, by jumps greater than the total estimated world oil resources. Production techniques are shifting from fully automated underground mines to gigantic surface mines with annual capacities of some tens of millions of tons. Coal slurry pipelines will be used for transportation, and sophisticated processes can transform coal into almost any other fuel: gas, syncrude, methanol, gasoline, and so on.
How do the various nations, whether producers or consumers or both, react to these changing conditions? And what could be the effects on the future world energy balance, and on a potential world coal market trying to compete with the world oil market?
All these questions--and many others--were raised and dealt with during the Third IIASA Conference on Energy Resources, devoted to Future Coal Supply for the World Energy Balance. More than seventy experts from East and West--technicians, economists, futurologists, modelers--contributed. The papers presented in this book treat technical aspects and prospects and economic (national, international, and global) problems and perspectives