Blog
This section has been created to put some informations of my day-of-day, when i have nothing to do and wanna write somethings.
Lots of experiences and histories may be put here, or nothing ;) I dunno...
The real motivation for this area is because i need to write some blogs for my master degree!! (interesting home-work)
I posted some blog entries in other pages:
- http://www.linuxnewmedia.com.br/blogs/seguranca/microsoft-ita/
- http://www.linuxnewmedia.com.br/blogs/seguranca/forense/
- http://www.linuxnewmedia.com.br/blogs/seguranca/defcon/
- http://www.linuxnewmedia.com.br/blogs/seguranca/h2hc6/
- http://www.linuxnewmedia.com.br/blogs/seguranca/phracksmm/
- http://www.linuxnewmedia.com.br/blogs/seguranca/phrackcell/
- http://www.linuxnewmedia.com.br/blogs/seguranca/lm-ips/
- http://blogs.securiteam.com/index.php/archives/1259
- http://blogs.securiteam.com/index.php/archives/1169
- http://blogs.securiteam.com/index.php/archives/1094
- http://blogs.securiteam.com/index.php/archives/738
- http://blogs.securiteam.com/index.php/archives/650
05/03/2007 - Sumitomo Bank Case
Recentemente li o caso do banco Sumitomo na Inglaterra. Trata-se de um grande banco japones que quase sofreu uma fraude por computadores no valor de U$$ 424 milhoes!
O caso foi avisado a policia (um exemplo a ser seguido pois permite toda a comunidade evitar futuros erros semelhantes).
Tratou-se de um keylogger instalado nos computadores do pessoal do help desk, que permitiram a captura de senhas de acesso remoto a diversos equipamentos do banco, inclusive aqueles utilizados para transferencias e controles de dinheiro entre contas.
A fraude contou com a ajuda de guardas que controlam acesso fisico, mas nao precisaria. Muito provavelmente um trojan enviado em um arquivo correto, por pessoa "confiA¡vel" de alguem no banco poderia ter surtido o mesmo efeito (ou atAC mesmo a exploracao de alguma falha client-side, como no software de correio ou navegador).
Este tipo de golpe tambACm ajuda a toda a comunidade de seguranca a enfatizar a
necessidade do uso de autenticacao forte em equipamentos criticos da empresa, pois se tivessemos por exemplo o uso de tokens OTP, tal tipo de ataque nao teria sido possivel.
03/05/2007 - A taxonomy of computer security flaws, with examples - by Carl E. Landwehr, Alan R. Bull, John P. Mcdermott and Williams S. Choi
O artigo propoe uma metodologia para organizacao de informacoes sobre falhas de seguranca, baseando-se no principio amplamente adotado em engenharia de software de que entendendo como/por que/onde os softwares falham pode-se construir um
software resistente a falhas.
Com a proposta pode-se ter uma melhor visao de qual parte de um sistema costuma
ter mais falhas e onde no ciclo de desenvolvimento do software as mesmas sao comumente inseridas.
Interessante que a ideia de taxonomia nao envolve apenas uma estrutura de categorizacao de dados (especimes) e sim um elemento capaz de armazenar algum historico das informacoes, definindo o que precisa ser armazenado e como tais informacoes diferem entre si.
Na taxonomia proposta, analisa-se um sistema operacional capaz de estabelecer uma politica de seguranca, levando-se em consideracao 3 questoes primarias:
- Como a falha entrou no sistema (chamado de genesis)
- Quando a falha entrou no sistema
- Onde no sistema a falha se manifesta
Interessante que o modelo observa na introducao de falha (genesis) se a mesma foi intencional ou nao, mostrando-se um modelo consistente e aplicavel tanto para
sistemas de codigo aberto quanto de codigo fechado. O fato de falhas intencionais poderem ser nao maliciosas mostrou-se muito importante, pois como o proprio artigo oferece como exemplo, um recurso para debugging remoto do software pode ser utilizado para explorar o mesmo, portanto AC uma falha introduzida intencionalmente (ja que AC um recurso do sistema) no entanto sem propositos maliciosos. Isto demonstra como o modelo cobre diversas situacoes comumente vistas no desenvolvimento de sistemas.
O modelo tambem mostrou-se completo na identificacao de quando a falha entrou no sistema, envolvendo nao apenas os amplamento observados ciclo de desenvolvimento e de manutencao, como tambem a fase de operacao do sistema (modificacoes nao autorizadas tais como patchs-on-the-fly podem inserir codigo malicioso em um sistema em operacao).
Na localizacao da falha introduzida no sistema o modelo mostrou-se surpreendentemente dinamico, envolvendo tambem falhas de hardware, nao apenas exclusivamente
no software.
Como mostrou-se um modelo exclusivo para sistemas operacionais, o modelo considera que o mesmo apresenta os seguintes locais passiveis de falhas:
* Inicializacao do sistema
* Gerencia de memoria
* Gerencia de processos
* Gerencia de dispositivos (incluindo rede)
* Gerencia de arquivos
* Identificacao/Autenticacao
Para nao limitar as possibilidades, incluiu-se a modalidade desconhecida para falhas que nao se encaixem nas localidades acima.
O proprio artigo adverte que o processo de boot comumente nao mostra-se bem observado, sendo que existem situacoes em que o mesmo eh altamente completo (vide sistemas onde o processo de boot precisa ser autenticado, iniciativas como os chips TPM e criptografia de disco, entre outros recursos).
Uma das caracteristicas mais interessantes desta proposta do artigo foi o fato de abranger os softwares ditos de 'suporte', tais como compiladores. Realmente os mesmos podem facilmente ser burlados em um ambiente de desenvolvimento, dificultando-se a determinacao da insercao de codigo malicioso no sistema, pois limitar-se-ia a identificacao do mesmo apenas no codigo binario.
Obviamente falhas complexas apresentam dificuldades em serem encaixadas em categorias especificas, exigindo uma analise mais detalhada de cada caso e determinacao de um padrao para cada tipo de analise desenvolvida (sugirou talvez enfocar nas prioridades de falhas baseadas em uma analise de risco do sistema analisado).
O apendice do artigo analisa diversos exemplos de falhas conforme a taxonomia proposta em diversos sistemas operacionais.
03/05/2007 - SHA1 - Descricao do Algoritmo
1.0-) História
SHA quer dizer Secure Hash Algorithm e mostra-se como um dos mais utilizados algoritmos de Hash da atualidade.
SHA-0 foi inicialmente proposto na norma FIPS 180 (Maio, 1993) como o padrao para algoritmos de hash do governo norte-americano, sendo porém substituido pelo SHA1-1 na FIPS 180-1 (Abril, 1995) [1]. O SHA1 adicoina uma operaçao de rotaçao circular que aparentemente foi adicionada para superar as fraquezas apresentadas
pelo SHA-0.
Atualmente, tanto o SHA-0 quanto o SHA-1 apresentam testes criptográficos aparentemente capazes de se gerar colisoes (o SHA-1 devido as modificaçoes incluidas,
mostra-se mais resistente a tais situaçoes, mas vem sendo colocado a prova constantemente). Devido a necessidades de resumos maiores, o NIST publicou outras funçoes de hash para a família do SHA [2], nomeadas SHA-256, SHA-384 e SHA-512 (com resumos de 256, 384 e 512 respectivamente). Tal publicaçao se deu em 2001, no esboço da norma FIPS 180-2 [3]. Em 2004 esta mesma norma foi modificada, para adicionar mais uma variante conhecida como SHA-224, criada para bater com o tamanho de duas chaves Triple DES (patente americana 6.829.355) [4].
2.0-) Descriçao
Este artigo enfoca o SHA-1, por ser o mais amplamente difundido e utilizado na atualidade.
As operaçoes matemáticas necessárias para o SHA, dado as palavras de 32 bits (x,y,z) e os operadores ^ (AND), ? (OR), ! (NOT), ? (XOR) e ? (rotaçao circular para a esquerda - adicionado ao SHA1).
F(x,y,z) = (x ^ y) ? (!x ^ z)
G(x,y,z) = x ? y ? z
H(x,y,z) = (x ^ y) ? (x ^ z) ? (y ^ z)
Salienta-se que o SHA utiliza-se de palavras de 32 bits, portanto as operaçoes demonstradas deverao ser todas entendidas como módulo 32 e o mesmo também faz uso de notaçao "big-endian" [5].
3.0-) Passos do algoritmo
1.O SHA faz uso de blocos de bits de 512, precisando portanto complementar as entradas de forma a serem múltiplas deste valor.
Para X o número de bits de uma mensagem (Ms) da qual se deseja calcular
o resumo e portanto 0?X??.
Têm-se que a Ms será concatenado um bit com valor 1.
Concatena-se também a Ms a sequência de [(447-X) mod 512] bits com o valor 0. Dado W uma palavra de 64 bits, faz-se S = X mod (2 elevado a 64).
Em Ms será concatenada a representaçao "big-endian" (conforme mencionado, o SHA entende que usa-se "big-endian" [5]) de S.
Desta forma, pode-se formar um Ms divisível por 512 conforme segue:
{Ms original, 1, 0, 0, 0, ..., 0, 0, 0, N mod (2 elevado 64)}
Onde:
Ms original possui N bits
N mod (2 elevado a 64) possui 64 bits
E o restante possui (447-N) mod 512 bits
Após este procedimento, têm-se uma Ms divisível em blocos de 512 bits.
2. Definiçao das constantes Hexadecimais de 32 bits
A=6745.2301
B=EFCD.AB89
C=98BA.DCFE
D=1032.5476
E=C3D2.E1F0
3. Agora repete-se de 1 até o número de blocos de 512 bits que compoe o
dado a ser feito hash
A2=A
B2=B
C2=C
D2=D
E2=E
4. Forma-se um bloco Msi composto de 16 palavras de 32 bits
5. Tendo-se W como um conjunto de 80 palavras de 32 bits, repete-se de 1 ate 16 a atribuiçao:
W1...16 = Msi1...Msi16
6. Repete-se agora de 17 até 80:
W17...80 = (Wvalor-3 ? Wvalor-8 ? Wvalor-14 ? Wvalor-16)
7. Agora repete-se de 1 até 20:
T=(A?5)+F(B,C,D)+E+Wvalor+5A82.7999
(E,D,C,B,A)=(D,C,B?30,A,T)
8. Após, deve-se repetir de 21 até 40:
T=(A?5)+G(B,C,D)+E+Wvalor+6ED9.EBA1
(E,D,C,B,A)=(D,C,B?30,A,T)
9. De 41 até 60, faz-se:
T=(A?5)+H(B,C,D) +E+Wvalor+8F1B.BCDC
(E,D,C,B,A)=(D,C,B?30,A,T)
10. Finalmente, de 61 até 80 têm-se:
T=(A?5)+G(B,C,D)+E+Wvalor+CA62.C1D6
(E,D,C,B,A)=(D,C,B?30,A,T)
11. (A,B,C,D,E) = (A+A2, B+B2, C+C2, D+D2, E+E2)
12. Para terminar, obtém-se o hash final através da concatenaçao dos valores de A, B, C, D e E.
Figura 1. Uma das interaçoes da funçao de compressao SHA-1.
4.0-) Ataques
Um grande exemplo de forma de ataque contra este tipo de algoritmo esta na possibilidade de colisoes ja divulgadas.
O algoritmo MD5 especificamente mostrou-se inadequado para algumas implementacoes mas ainda efetivo para diversos usos (a quebra exige a modificacao de um arquivo original e a consequente geracao de um outro arquivo diferente que bata com o novo arquivo modificado - observa-se que ainda nao existe prova teorica da criacao de um arquivo que o hash bata com o do original em si).
As implementacoes deste tipo de algoritmo sao diversas, sendo comumente vistas no armazenamento de senhas, onde armazena-se apenas o hash da senha fornecida, e
na autenticacao verifica-se o hash da senha informada pelo usuario com o hash armazenado. Isto permite que caso o sistema de senhas seja comprometido, as senhas nao possam ser determinadas. Tal tipo de implementacao mostra-se viavel pois
a computacao de hash de algoritmos mostra-se extremamente rapida.
Outros usos menos comuns envolvem verificacao de executaveis antes da execucao dos mesmos, sendo o software md5verify [6] (desenvolvido por Richard Johnson e portado para kernels 2.6 (LSM) e adicionado recursos de verificacao de SHA1 por Rodrigo Rubira Branco - eu) um bom exemplo de tal tipo de implementacao.
5.0-) Indice de Figuras:
Figura1: Interaçao do SHA-1
Fonte: http://en.wikipedia.org/wiki/Image:SHA-1.png
6.0-) Referências:
[1] Página sobre hashs criptográficos do NIST, http://csrc.nist.gov/CryptoToolkit/tkhash.html. Acessado em: 06/06/2006.
[2] Página descrevendo as diferenças entre os diversos hashs da família SHA, http://en.wikipedia.org/wiki/SHA-2. Acessado em: 06/06/2006.
[3] Revisao da norma FIPS 180-2, http://csrc.nist.gov/publications/fips/fips180-2/fips180-2withchangenotice.pdf. Acessado em: 06/06/2006.
[4] RFC sobre o SHA-224, ftp://ftp.rfc-editor.org/in-notes/rfc3874.txt. Acessado em: 06/06/2006.
[5] Página explicativa sobre little/big endian, http://www.cs.umass.edu/~verts/cs32/endian.html. Acesso em: 06/06/2006.
[6] md5verify, http://rjohson.uninformed.org. Acesso em: 03/05/2007.
03/05/2007 - Enigma
A maquina enigma, famosa por seu uso pelo governo alemao durante a segunda grande guerra mundial contava com diversos rotores e o uso de reflexao para permitir
o uso de uma chave para cifragem e decifragem de dados. Ela gerava bilhoes de possibilidades, tornando a quebra por forca bruta ou a criptoanalise um fator extremamente 'impossivel'. Creio que seja o melhor exemplo de que o elo mais fraco da seguranca mostra-se como o fator humano.
Abaixo uma implementacao em C da logica provida pelo enigma:
/* Simulador da maquina "Enigma" com 3 rotores */
#include
#define POS_C(x,y) printf("\x1B[%d;%df",x,y)
#define LIMPA printf("\x1B[2J")
/* Valores para os rotores (isso eh de cada fabricante) */
char rotor[5][26]={
/* Input "ABCDEFGHIJKLMNOPQRSTUVWXYZ" */
/* 1: */ "EKMFLGDQVZNTOWYHXUSPAIBRCJ",
/* 2: */ "AJDKSIRUXBLHWTMCQGZNPYFVOE",
/* 3: */ "BDFHJLCPRTXVZNYEIWGAKMUSQO",
/* 4: */ "ESOVPZJAYQUIRHXLNFTGKDCMWB",
/* 5: */ "VZBRGITYUPSDNHLXAWMJQOFECK" };
char ref[26]="YRUHQSLDPXNGOKMIEBFZCWVJAT"; // chave
char notch[5]="QEVJZ";
int flag=0;
int flag2=0; /* definir se esta no texto claro ou no texto cifrado */
/* Parametros de criptografia */
char order[3]={ 3, 1, 2 };
char rings[3]={ 'W','X','T' };
char pos[3]={ 'A','W','E' };
char plug[]="AMTE";
int main()
{
int i, j;
int n=0;
int ch;
LIMPA;
POS_C(0,0);
printf("------------ Texto claro ------------");
POS_C(2,0);
while( (ch=getchar() ) != EOF)
{
ch=toupper(ch);
if ( ch == '\n' )
{
printf("\n\n------------ Texto claro ------------\n");
flag2=0;
}
else
{
if ( flag2 == 0 )
{
printf("\n\n------------ Texto cifrado ------------\n");
flag2=1;
}
}
/* Nao for caractere alphanumerico */
if (!isalpha(ch))
continue;
/* Primeiro rotor */
pos[0]++;
if (pos[0]>'Z')
pos[0] -= 26;
/* Verifica se o segundo rotor atingiu o fim da ultima vez */
if (flag)
{
/* Segundo e terceiro rotores */
pos[1]++;
if (pos[1]>'Z')
pos[1] -= 26;
pos[2]++;
if (pos[2]>'Z')
pos[2] -= 26;
flag=0;
}
/* Acerta segundo rotor se o primeiro rotor atingiu o fim */
if (pos[0]==notch[order[0]-1])
{
pos[1]++;
if (pos[1]>'Z')
pos[1] -= 26;
/* flag=1 se atingiu fim do segundo rotor */
if (pos[1]==notch[order[1]-1])
flag=1;
}
/* Troca o par de letras no visor */
for (i=0; plug[i]; i+=2)
{
if (ch==plug[i])
ch=plug[i+1];
else if (ch==plug[i+1])
ch=plug[i];
}
/* Move rotores adiante */
for (i=0; i<3; i++)
{
ch += pos[i]-'A';
if (ch>'Z')
ch -= 26;
ch -= rings[i]-'A';
if (ch<'A')
ch += 26;
ch=rotor[order[i]-1][ch-'A'];
ch += rings[i]-'A';
if (ch>'Z')
ch -= 26;
ch -= pos[i]-'A';
if (ch<'A')
ch += 26;
}
/* Rotor de reflexao */
ch=ref[ch-'A'];
/* Move rotores para tras */
for (i=3; i; i--)
{
ch += pos[i-1]-'A';
if (ch>'Z')
ch -= 26;
ch -= rings[i-1]-'A';
if (ch<'A')
ch += 26;
for (j=0; j<26; j++)
if (rotor[order[i-1]-1][j]==ch)
break;
ch=j+'A';
ch += rings[i-1]-'A';
if (ch>'Z')
ch -= 26;
ch -= pos[i-1]-'A';
if (ch<'A')
ch += 26;
}
/* Visor */
for (i=0; plug[i]; i+=2)
{
if (ch==plug[i])
ch=plug[i+1];
else if (ch==plug[i+1])
ch=plug[i];
}
n++;
putchar(ch);
if (n % 5 == 0)
if (n % 55 == 0)
putchar('\n');
else
putchar(' ');
} // fim do while
}
O enigma foi quebrado baseando-se em diversos fatores, mas como mais importante
deles mostrou-se o erro humano dos operadores.
Maquinas enigma ja haviam sido obtidas pelos poloneses enquanto as mesmas estavam comercialmente disponiveis e conjuntos de textos cifrados, claros e respectivas chaves foram fornecidas por traidores. Isto permitiu determinar-se a logica dos rotores alemaes e assim construir-se equipamentos enigma similares aos utilizados na epoca da guerra.
No entanto as chaves diarias ainda precisavam ser obtidas, e o desprepado dos operadores de mensagens alemaes foi crucial neste passo.
Primeiramente diversas mensagens eram repetidamente enviadas no inicio da comunicacao. Outro erro comum envolvia o envio de mensagens com a chave antiga, sem haver-se atualizado os equipamentos com as novas chaves diarias, permitindo-se assim o uso de pares de mensagens cifradas e nao cifradas por parte dos aliados.
Importante notar que a repeticao de conjuntos de mensagens permitia aos aliados
inclusive identificar qual o operador estava enviando determinada mensagem! Algo surpreendente dado que tratava-se de um texto cifrado, considerado INQUEBRAVEL pelos alemaes.
15/11/2006 - Comparativo entre sistemas de gestao empresarial OpenSource (openerp) e Comerciais (SAP) por Gabriel Negreira, Nelson Alves Pinto e Rodrigo Rubira Branco
Objetivos:
Este artigo visa demonstrar onde os sistemas de cóo livre podem ser utilizados dentro de um ambiente corporativo, fundamentando seus pontos positivos e clarificando os pontos negativos (recursos nao existentes ou nao providos), permitindo assim uma melhor escolha por parte de corporacoes para a adocao de codigo livre (e gratuito) em projetos de sistemas de gestao empresarial
Publico Alvo:
Dado o objetivo apresentado este artigo melhor encaixa-se para administradores de TI e gestores de micro e pequenas empresas, dado que os sistemas de gestao open-source ainda apresentam-se carentes em suporte e consultoria especializada para implementacao em larga escala.
Introducao:
Os sistemas open-source (com o codigo amplamente disponivel e em sua maioria gratuitos) estao crescendo em diversas areas da computacao e nao poderia ser diferente para sistemas de gestao empresarial (amplamente considerados projetos dispendiosos, muito complexos e de dificil personalizacao).
Como trabalho para a materia de mestrado no Instituto Tecnolóo da Aeronáica (ITA) de gestao de processos de desenvolvimento de software, com o Prof. Yano, compara-se aqui duas ferramentas de ERP, focando-se uma comercial (e amplamente utilizada), da empresa SAP, para micro e pequenas empresas e outra open-source
(e pouco conhecida), openerp (gratuita e com codigo fonte disponivel, desenvolvida em Java e outras tecnologias de ultima geracao como AJAX).
Importante salientar que embora o OpenERP tenha sido escolhido, ele nao representa o mais usado e confiál sistema de gestao empresarial open-source. O mesmo
foi escolhido pois trata-se de um software desenvolvido no Brasil (e por brasileiros). Tambem serve como um comparativo entre solucao opensource versus solucoes de codigo fechado neste segmento.
Analise Inicial (ou resumo executivo):
A ferramenta SAP mostra-se muito completa mesmo em seu modelo SMB, mas ainda fora da realidade de micros e pequenas empresas brasileiras (a SAP nao possui produtos para micro empresas, sendo SMB o mercado de pequenas e méas). O valor do
software analisado ém torno de R$ 200 mil, mais as horas do consultor para implementacao e correta modelagem do negocio.
Em outra ponta, temos a ferramenta openerp, que possui integraç com diversas funcionalidades, mas ainda mostra-se carente na correta modelagem e expansao de negós. Possui óos recursos de CRM (opencrm seria uma ferramente com esta funcionalidade especíca) e fundamentalmente ém software WEB (executado em m java). Por ser uma ferramenta com cóo disponíl e desenvolvida em uma linguagem amplamente conhecida, torna-se fál sua expansao, sendo a hora de um consultor (programador) muito mais barata do que a oferecida pelos produtos comerciais.
Conclui-se aqui que a menos que a empresa tenha necessidades reais de total integraç de múlos setores, negós complexos (que precisam ser bem entendidos e modelados, com poucas exclusividades próas, mas caracteríicas gerais do
modelo de negó amplamente conhecido) a resposta seria o uso de uma ferramenta comercial como o SAP.
Modulos disponiveis:
A ferramenta da SAP pode facilmente ser incrementada, com a incorporaç de móos adicionais (aumentando-se o valor da soluç), suportando, entre outras coisas:
- BI (ferramenta de inteligêia de negós, geraç de recursos para tomada de decisao e grácos em cubo que podem ser modelados conforme as informaçs que o
gestor julgar necessáo (exigindo horas de consultoria para escrita do codigo em linguagem propria))
- CRM (gestao do relacionamento de clientes, com base de conhecimento e históo, bem como acompanhamento de pedidos)
- Acompanhamento do modelo de negós (um dos fortes argumentos de venda para sistemas de gestao empresarial consiste no forte conhecimento de melhores prácas
de gestao de negós, incorporada nas ferramentas)
- Sistema baseado em web e tambéem modelo cliente-servidor.
- RH (oferecendo gestao de recursos humanos)
Atravéda ferramenta opensource analisada, temos as mesmas funcionalidades, destacando-se entretando que o móo chamado de BI apresenta-se extremamente limitado e de difíl expansibilidade, podendo ser visto apenas como uma visao gráca da situaç do banco de dados existente.
Obviamente, devido a inexistêia de grandes implementaçs destes softwares, têse uma limitaç relativamente grande no suporte aos diferentes modelos de negós, podendo o mesmo ser visto apenas como um sistema integrado de cadastros de clientes, produtos e serviç (bem como gestao de funcionáos e outras atividades afins).
Requisitos de Sistema:
Os requisitos necessáos diferem grandemente dos recursos utilizados e do porte da empresa e quantidade de máinas clientes.
Isto porque o OpenERP trata-se de uma ferramenta que roda exclusivamente no servidor, exigindo do sistema cliente apenas uma conexao de rede e um navegador. Este tipo de soluç totalmente baseada em WEB gera um trágo de rede muito grande, mas permite economias com a estaç (pois nao faz uso de recursos da mesma).
A soluç da SAP apresenta esta possibilidade, mas em geral prefere-se o uso de um cliente especíco da soluç (que permite maior dinamismo no uso, mas exige mais do equipamento cliente).
Como banco de dados de backend o SAP apresenta integraç com os principais bancos do mercado, sendo comumente visto o uso com banco de dados Oracle e MS-SQL Server (o que aumenta e muito o custo da soluç). O OpenERP mostra-se amplamente integrado com os bancos de dados open-source MySQL e PostgreSQL
Referencias Adicionais:
http://www.sap.com
http://openerp.persapiens.org/
15/11/2006 - Article: "Business processes for Web Services: Principles and applications" by A. Keller, F. Leymann and R. Khalaf
A linguagem de execuç de processos de negós (BPEL4WS ou BPEL) éma linguagem baseada em XML para definir os processos de linguagem e prover interoperabilidade, portabilidade (tanto para processos abstratos quanto para execucao) e foi
desenvolvida desde o principio para operar conforme a heterogenidade e dinamismo necessarios e comuns em ambientes tecnologicos atuais.
BPEL éonstruida em camadas de flexibilidade providas pela pilha de servicos WEB e conta especialmente com XML. Neste trabalho os autores forneceram uma introducao a mesma com enfase na arquitetura e conceitos basicos. Tambéabordaram como BPEL pode ser aplicada em diversas areas de uma aplicacao, tais como adicao
de qualidade de servico, extencao de BPEL para envolvimento de atividades que possuem pessoas, grid computing e computacao autonoma. Com este resumo enfoquei nos recursos que a linguagem oferece e nao como sao fornecidos.
Um workflow consiste em atividades que executam acoes e um fluxo de controle que governa a ordem destas atividades. Atualmente, os WFMS (workflow management systems - sistemas de gerenciamento de workflow) possuem formatos proprietarios e
por isso sao de dificil compartilhamento de informacoes.
Com a ascensao de SOA (service oriented archictecture - arquitetura orientada a
servicos), temos o uso mais comum de frameworks baseado em webservices, que consistem em padroes e especificacoes escritas em XML para definir os servicos, interfaces e controles bem como garantir a qualidade e requisitos.
Os webservices fazem uso da WSDL (web service description language - linguagem de descricao de servicos web) para especificar quais sao as funcoes e como interagir com as mesmas.
BPEL foi originalmente lancada em 2 de Julho de 2002 como BPEL4WS V1.0, uma joint venture entre BEA Systems, Inc., IBM Corporation (oba oba oba) e Microsoft Corporation. BPEL4WS surgiu da junç de recursos de geracao de graficos de definicao de processos da IBM Web Services Flow Language (WSFL) com as construcoes estruturais abordadas pela XLANG da Microsoft.
Duas necessidades para este tipo de linguagem existem e sao fundamentais: portabilidade e interoperabilidade.
Portabilidade permite que processos de negocio padronizados possam ser utilizados por multiplas organizacoes. Interoperabilidade permite que tais processos possam ser utilizados para se 'comunicar' com multiplos outros processos e sistemas totalmente diferentes, permitindo assim o uso em web services.
Unidades pequenas de execucao podem ser suportadas por escopos atomicos (de execucao continua). Atividades que sao implementadas como programas transacionais podem ser agrupados em escopos definidos com semantica ACID (atomicity (atomicidade), consistency (consistencia), isolation (isolacao) e durability (durabilidade)): ou todas as transacoes sao completadas dentro do escopo executado, ou todas sao voltadas ao estado original.
Diversos padroes de processos podem ser fornecidos e desenhados com o uso desta
linguagem de descricao de processos, sendo muito utilizados para compatiblidade
e fornecimento de buscas, bem como para comercio eletronico com o fornecimento de interfaces padroes.
Com o uso do Web Services Policy Framework (WS-Policy) pode-se adicionar qualidade de servico (QoS) diretamente nas especificacoes, permitindo assim os recursos serem corretamente distribuidos entre multiplas aplicacoes.
Atraves do uso do flow definition map language (FDML - linguagem de mapeamento de fluxo) pode-se inclusive utilizar-se o uso de pessoas nos processos, onde os mesmos exigem interacao humana, mostrando-se como tal ferramenta éoderosa na modelagem de processos multi e inter empresas.
O open grid services architecture (OGSA) fornece os recursos de web-services para uso em grid, tendo como exemplo a aplicacao Set@home de busca de alienigenas.
Tal tipo de computacao faz uso da WebServices Resource Framework (WSRF ou WS-Resource) para saber as propriedades que podem ser buscadas a qualquer momento e o que devera ser calculado.
Sistemas autonomos sao auto-gerenciados, ou seja, sao capazes de executar independentemente da acao de operadores. As estatisticas mostram que os erros de operacao sao a principal causa de problemas em sistemas computacionais. Com o uso de um padrao de comunicacao, pode-se implementar gestores computacionais automatizados, capazes de tomar acoes e garantir niveis de servico (SLA) facilmente e auto-gerenciados.
O artigo ainda aborda alguns detalhes na escrita desta linguagem e em uma implementacao utilizando-se de J2EE e ferramentas IBM, que nao foram aqui abordados pois estarem fora do escopo deste blog.
15/11/2006 - Article: "The Joy of Flex" by JOHN HAGEL and JOHN SEELY BROWN (portuguese only)
O artigo aborda claramente a necessidade de modularidade e padronizacao das formas de descricao de informacoes contidas em cada modulo.
Um dos avancos fornecidos para a tecnologia de Web Services pode ser visto com a Web Services Description Language (WSDL), que define um conjunto de padroes para a criacao de documentos que descrevem os servicos oferecidos, como estes se comunicam e onde podem ser encontrados.
Inovacao atraves da recombinacao de modulos épenas o comeco. A idé de um acoplamento fraco (loose coupling) facilita o incremento rádo de inovacoes com
novos modulos. Reduzindo-se as interdependencias entre os modulos, o acoplamento fraco permite o experimento mais facil de novas funcionalidades e a melhoria de modulos sem ter de se preocupar com disrupturas em outras partes de um sistema complexo. Neste contexto, o acomplamento fraco no nivel de TI amplifica o potencial para a ráda inovacao inclusive nos niveis de negocios.
Atravéde processos com acoplamento fraco a Li & Fung mantem interligacoes de mais de 7.500 parceiros de negocios no mundo.
A Li & Fung consegue orquestrar e gerenciar esta complexa e extremamente flexivel rede porque mantem o foco na definicao de formas padroes de especificacao de saida de dados para cada parceiro e deixa as decisoes sobre como executar estas saidas para cada um dos parceiros. Como um exemplo, o artigo menciona que a mesma apresenta uma forma padronizada de representar cores, porem nao menciona como
os parceiros devem produzir tal cor.
Os parceiros nao precisam implementar uma determinada tecnologia, mas sim usar seus proprios sistemas e apenas utilizar os servicos providos pela Li & Fung.
Uso de acoplamento fraco normalmente éeito nas extremidades de relacoes entre
empresas, e exige um investimento em processos negocios e confianca muito profundos entre os participantes. espera-se que em breve seu uso seja expandido tambem internamente nas empresas.
Os CIOs possuem papel fundamental neste novo componente de negocio, pois entendem a tecnologia, conhecem do negocio e podem facilitar o conhecimento por parte dos executivos de outras areas a respeito das novidades e vantagens deste novo modelo.
15/11/2006 - Another blog entry in Securiteam
Copy and Paste Security Bugs?? The *BSD case
bsdaemon - November 15, 2006 on 8:51 pm
So, it's time to another blog entry, another idiot/dumb post...
http://www.securityfocus.com/archive/1/451637/30/0/threaded
http://www.securityfocus.com/archive/1/451629/30/0/threaded
And for sure DragonFlyBSD and TrustedBSD* are also affected for this issue... why?
The bug occur because bsd developers does not know how integer convertion is done? Or just because you have copy and paste the bug from another BSD to yours? Itâs always a problem when you copy code from another location. How secure is that code? What is the historical security problems it has? Let's audit it!
Congratulations to you, OpenBSD guys, who simply don't support things you don't audit... why someone wanna use firewire? hehehe . Yeah! Is pretty easy talk
about problems, but, how I can help to solve it? I really dunno... In my mind, you need to understand the code you are copying, but, for god, please, copy it ;)
Cya,
Rodrigo Rubira Branco (BSDaemon).
15/11/2006 - My first blog entry in Securiteam
Vulnerability Disclousure Pratices in Open-Source Systems
bsdaemon - September 29, 2006 on 3:50 am
A lot of discussion has been done worldwide about the disclousure (or not) of new information systems vulnerabilities.
First we have people who like full-disclousure (bug-details, including how to explore it and an exploit for it), in the other hand, who doesn't agree on the vulnerability disclousure (need the disclousure of patches, not the details of what bug it corrects).
This kind of idea facilitates the attackers' sucess (they just need to verify
the differences between a system and the patched version of this system, using bindiff tools to help in this process). The users, who don't need to really update systems (just update when a security flaw exists not just because an update
exist) can't know when is secure not update the system (so, let's sell more
systems...).
My first blog entry does not try to discuss it, but discuss this position:
"The policy of the FreeBSD Security Team is that local denial of service bugs
not be treated as security issues; it is possible that this problem will be corrected in a future Erratum"
Interesting to see this kind of answer for a security problem in the system, mainly when the bug can be exploited (yeah, it can be exploited).
But, local denial of service is not a problem? Hum, sorry for hosting companies
who uses FreeBSD!!
Cya,
Rodrigo Rubira Branco (BSDaemon).
03/10/2006 - Comentários do artigo: "McDonald's: McBusted" (portuguese only, because i have no time to translate)
Este artigo aborda um projeto ousado, chamado de innovate pelo pessoal do McDonald's, que visava um investimento de U$$ 1 bilhão e foi abandonado após U$$ 170 milhões investidos, para integracão de todas as lojas da rede.
Segundo dados da própria empresa, 1 em cada 10 americanos já trabalhou no McDonald's, mostrando-se assim como uma empresa de alta-rotatividade e grandes gastos em qualificacão de pessoal segundo as normas da companhia.
A intencão era utilizar ERP oracle em máquinas SunFire rodando Unix para substituir todos os sistemas de financas, supply-chain, recursos humanos e back-office. Ligar 30000 restaurantes e mais de 300 fornecedores, 24 horas por dia, 7 dias por semana aos sistemas de gerência da corporacão central.
Se a empresa consegue, por exemplo, eliminar a necessidade de um trabalhador em determinado processo, economizaria com isto U$$ 82.40 por dia, vezes 30000 restaurantes (entre próprios e da rede de franchising), a economia seria de U$$ 900 milhões ao ano, mostrando-se que o sistema poderia facilmente obter um ROI (return of investment) adequado.
Nesta nova tecnologia integrada também incluia-se o monitoramento das máquinas essenciais, antecipando-se a problemas e reparos, mas principalmente garantindo-se a qualidade necessária para cada um dos lanches oferecidos (sempre a mesma temperatura, tempo de cozimento, e assim por diante).
Para exemplificar a dificuldade da empresa, imagine que um hamburguer precisa de uma temperatura exata (140 graus) para não permitir desenvolvimento de uma bactéria que pode ser fatal (gerando assim milhões em perdas processuais decorrentes, sem falar da vida humana).
Como 70% dos restaurantes são franchising, o McDonald's comecou a idéia com seus próprios restaurantes, evitando assim a resistência (decorrente de insucessos anteriores), e como a maioria dos restaurantes da Europa são da própria empresa, comecou-se por lá os projetos.
Uma das grandes dificuldades encontradas neste projeto "visionário" apresenta-se em conectar todos os lugares em banda-larga, especialmente no terceiro mundo, e também quesitos de seguranca (que poderiam ser reduzidos com tecnologias como vpn segundo a empresa).
Outras iniciativas do McDonald's receberam resistência nos EUA, como um sistema chamado made for you (feito para você), que visava automatizar a producão de bigmacs, gerando um custo total de 30 a 40k para a loja (instalacão), o que representa um terco do total recebido anualmente (detalhe, o software atrasou a entrega dos lanches, ao invés de agilizá-la como prometido).
Outras iniciativas tomadas foram implementacão de RFID para cartões (pagamentos com cartões levam de 30 a 50 % mais tempo segundo a própria VISA), impressões digitais (também para cartões), mas os consumidores não gostaram da idéia de ter suas impressões colhidas pela companhia.
A definicão de pontos de decisão para a escolha do fornecedor é fundamental, escolhendo-se primeiro o software, depois o hardware e por último o integrador (que fará tudo isto funcionar corretamente).
Um dos problemas é que a empresa sabe quantas matérias primas são vendidas por lojas (após uma semana), mas não quantos lanches especÃficos (venderam-se 1000 hambúrgueres, mas quantos desses foram para um X-Burguer?).
Existe grande dificuldade de se implementar tecnologia na empresa devido a cultura organizacional e aos insucessos do passado.
O McDonald's por exemplo já tentou desenvolver seu próprio POS (point of sale), usando sofware desenvolvido internamente, por motivos estratégicos, e hardware baseado em pc, conseguindo metade do valor (15 a 20k por restaurante) do que solucões de mercado. Tal projeto diminuiu a velocidade do atendimento (ao invés de aumentá-la como prometido).
Collaborative Planning, Forecasting and Replenishment (CPFR) seria o sistema utilizado pela gerência, que não era integrado e mandava os resultados em batch, dividido em duas partes, o POS e mais um sistema ISP que ficava na loja, implementado em SCO Unix (o único unix comercial para PC na época). Claramente este projeto não poderia dar certo...
03/10/2006 - Comentários do artigo: "7-Eleven Japan: Reinventing the Retail Business Model" (portuguese only, because i have no time to translate)
A 7-Eleven possuÃa 24912 lojas em marco de 2003 em 18 paÃses. As leis japonesas sempre favoreceram as pequenas lojas (já que o paÃs possui pouco espaco disponÃvel, tais leis foram abolidas, mas impactaram e muito o comportamento das empresas no paÃs). Também importante entender que o sistema de distrubuicão no Japão é mais baseado em relacionamentos do que em custos, o que dificulta empresas estrangeiras atuarem fortemente neste mercado.
Já em 1960 a SEJ (7-Eleven Japão), então conhecida como Ito-Yokado, descobriu o modo de se tornar de pequenas e improdutivas lojas em uma rede conectada de representantes (franchising), onde os conhecimentos seriam passados pela matriz (este era o modo de se fazer na 7-Eleven dos EUA).
O mercado achava que o Japão estaria saturado, devido a grande quantidade de pequenas lojas, mas mesmo assim a união entre as empresas foi feita em 74, e a primeira loja 7-Eleven foi aberta no Japão.
O entendimento do mercado local mostra-se essencial, principalmente em se tratando do Japão, que possui hábitos extremamente diferentes que precisariam ser adaptados do modo de se trabalhar da 7-Eleven EUA (por exemplo, os japoneses gostam de qualidade e atendimento rápido, e não se importam tanto com o preco). Dai surgiu a necessidade da disponibilidade de produtos diferenciados, 24 horas por dia, 7 dias da semana, nunca faltando o que o cliente deseja.
Os fundamentos da SEJ são realmente de uma loja de conveniência, provendo produtos que tornem a vida de seus clientes mais fácil e ágil, bem como em casos de emergência sejam necessários.
PrincÃpios fundamentais da empresa:
- Não faltar o produto (nunca deixar de vender por falta do item)
- Suprir produtos de forma rápida, analisando-se as necessidades e mantendo cadeia de fornecimento ágil e pró-ativa
- Realmente entender as necessidades dos clientes para atende-las
Desde 1982 a SEJ introduziu um POS (point of sale) para armazenar informacões de padrões e perfis de compras (o caixa nem sequer consegue efetuar uma venda sem que dê entrada na idade aproximada do comprador). Isto permite que os estoques sejam mantidos de produtos que realmente têm potencial de saÃda e que a loja seja organizada conforme os horários de atendimento (vários itens são repostos também durante todo o dia).
Para a abertura de novas lojas (franchising), mais de 135 fatores sao levados em consideracao, sendo que o faturamento diario medio de uma loja da SEJ supera em 35% o de outras competidoras no setor.
A SEJ tbm possui 1300 OFC's (operation field counselors) cada um supervisionando de 7 a 8 lojas (isto permite o engajamento homem-a-homem necessario para o japao).
Também reune todos os OFCs semanalmente em sua sede para troca de informacoes de uso e exige um treinamento de duas semanas para novos donos de lojas, bem como que trabalhem em uma das lojas centrais.
Ficou famosa pela terceirazacão, ao inves de criar sua propria cadeia de suprimento ela conta com fornecedores que possuem exclusividade de operacoes nas regioes, desde que elevem as capacidades e aumentem a demanda.
Em 2002 já contava com 223 centros de distribuicao e 195 empresas para fornecimento de fast-food.
O sistema mostra-se tao bom que as proprias empresas utilizam ele para ter ideia de como seus produtos sao vendidos e para que tipo de publico (outra caracteristica da SEJ esta neste compartilhamento de informacoes e know-how).
Mesmo os sistemas de TI da SEJ sao terceirizados (todo o desenvolvimento e gerenciamento é feito pela Nomura Research Instituite - a terceira maior prestadora de servicos de TI no Japao). Isto permite que a equipe de TI da SEJ faca planos de como os sistemas podem atender aos negocios e de novos desenvolvimentos tecnologicos a serem feitos.
A empresa sempre mostrou-se inovativa, em 1982 foi o primeiro POS do Japao, o primeiro grande uso de ISDN em 1991 entre outras...
Em 1999 criou um novo sistema em parceria com grandes fornecedoras de TI com os objetivos de:
- Conectar as lojas ao escritorio central, provendo informacoes extramemente rapidas atraves de redes isdn e satelite
- Fornecer informacoes para as lojas, em formato multimedia para facilitar o ciclo de informacoes de inventario das lojas e sua importancia
- Sistema de compartilhamento de informacoes com os parceiros (fornecedores, vendedores e manufaturas) conectando mais de 1800 terminais em 1100 localidades
- Analise de dados que permite que muitos dados sejam transformados em informacoes uteis aos negocios e na tomada de decisoes
Desde 1987 a SEJ possui um sistema de financas que permite diversas formas comodas de pagamento de contas aos clientes, o que se tornou um sucesso e atualmente trata-se de um dos maiores bancos no Japao.
Internet shopping é disponibilizado para pagamento de contas e entrega na casa dos clientes 24 hras por dia (mantido por uma subsidiaria da SEJ)
Servicos de entrega de produtos existem, permitindo também a compra via internet.
Maquinas de copia inteligentes conectadas a internet permitindo impressao de tickets e passagens aereas.
O sistema de entregas centralizado em pontos de distribuicao otimizou as entregas no menor numero possivel e necessario ao dia para garantia de eficiencia, com rotas de entrega otimizadas e inclusive possibilidade de entregas com outras formas (ex: helicopteros em casos de grandes congestionamentos).
Supply chain management e demand chain management sao incorporados e administrados como uma peca estrategica dentro da SEJ, fazendo com que a empresa reaja pro-ativamente as demandas dos consumidores
02/09/2006 - Comentários do artigo: "When Failure is Not an Option"; Technology Review; 1997 (portuguese only, because i have no time to translate)
O artigo aborda um estudo da universidade de Berkeley na California a respeito de empresas de alta-confiabilidade. Por mais de uma decada, Todd La Porte, Karlene Roberts, e Gene Rochlin estudaram grupos que faziam coisas que pareciam impossivel: operar sistemas complexos e essencialmente sem erros.
Como exemplo, foram estudados algumas instituicoes essencialmente complexas pelas caracteristicas de suas operacoes.
Um porta-avioes possui as dificuldades de um aeroporto muito ampliadas, ja que consta de pessoas jovens, alta-rotatividade e pousar em um navio mostra-se bem mais dificultoso do que o pouso em uma pista (que AC muito maior).
Aparentemente, este tipo de instituicao (o porta-avioes) mostra-se organizado como qualquer hierarquia tradicional, com a autoridade sendo de um captao e descendo atraves de patentes claramente definidas. A maioria das operacoes do dia-a-dia respeita esta hierarquia.
Durante um pouso, no entanto, as coisas mostram-se diferentes e a estrutura organiza-se de uma maneira completamente modificada. Nestes momentos, os membros da equipe interagem muito mais com os colegas e menos com os superiores e subordinados. A cooperacao e comunicacao passa a ser mais importante do que as ordens vindas de cima para baixo na linha de comando. Este mostra-se um momento muito critico para se esperar por instrucoes ou autorizacoes (qualquer coisa que der errada pode ser fatal). As pessoas agem como um time, comunicando-se constantemente via telefones, radios, sinais de mao ou escrita. Esta comunicacao constante permite a identificacao de erros antes que eles causem danos. Algumas pessoas
sao responsaveis por continuamente monitorar o que acontece, verificando se nada esta fora do lugar.
Os porta-avioes ainda podem ser organizados de uma outra forma, em caso de emergencias. Diversas tarefas sao dadas a membros da equipe para estas situacoes, onde cada um assumira suas responsabilidades sem qualquer tipo de direcao.
Cada uma das pessoas nestes momentos tem autoridade para por exemplo suspender uma operacao de voo, o que mostra que a organizacao perde realmente a hierarquia
tradicional nestes momentos. Julgamentos errados podem ser criticados futuramente apos uma revisao, mas nunca existira uma penalidade para estes, e geralmente
haverao congratulacoes por julgamentos certos. Isto garante que as pessoas continuarao tomando decisoes, sem medo de errar, mas para o bem de todos.
Outro tipo de empresa analisada foi uma instituicao nuclear, demonstrando o mesmo padrao de funcionamento, onde regras pre-estabelecidas existem para determinadas situacoes, algumas executadas por pessoas outras por computadores. Estas regrs existem para resguardar erros de omissoes por parte de pessoas que nao fazem algo que deveriam.
Hierarquias rigidas podem funcionar em sistemas que podem ser decompostos em partes independentes, ja que nao exigem interacao de todas as partes (uma nao afeta a outra), mas nao em sistemas totalmente interligado.
Por isso a comunicacao constante e a flexibilidade para mudar diante de diferentes situacoes mostra-se como a solucao para empresas que nao podem errar.
Obviamente o aprendizado continuo deve ser incentivado onde as pessoas podem continuamente questionar o que fazem, para poderem fazer o melhor.
E sem duvidas os erros nao sao punidos, mas utilizados para se aprender o porque um erro aconteceu e como evitar que aconteca novamente.
02/09/2006 - Comentários do artigo: "Software's Chronic Crisis"; Scientific American; September 1994 (portuguese only, because i have no time to translate)
Este artigo aborda de forma muito interessante o problema do desenvolvimento de
softwares mundialmente enfrentado.
Ve-se como comum grandes projetos de software tendo seus orcamentos e prazos extremamente estendidos do que era inicialmente esperado.
Condensado de exemplos, o artigo aborda esta questao e mostra como diversas organizacoes estao enfrentando o problema, desde os primordios da computacao, e longe de uma solucao definitiva.
As propostas oferecidas como definitivas, muitas vezes falham na pratica. O artigo salienta a importancia da existencia de laboratorios formais para testes de
engenharia de software jA¡ que "se a engenharia de software deve ser uma ciencia experimental, isto significa que precisa de laboratórios. Onde estao estes laboratórios?".
Dados mostram que menos de 10% das empresas americanas consistentemente medem a
produtividade de seus programadores. A indústria também nao possui um padrao
realmente util de mensuracao desse fator, onde muitos relatorios (incluindo em jornais de ciencia da computacao) expressao a produtividade em linhas de codigo por empregado por mes. Isto realmente torna-se inefetivo, ja que as linguagens de programacao sao variadas enormemente em complexidade. A qualidade do codigo gerado tambem acaba nao sendo considerada quando se mede apenas linhas do mesmo que foram geradas.
Com a crescente complexidade dos softwares, novos metodos de testes devem exitir. Tradicionalmente os desenvolvedores testam um programa executando-o da forma
como deveria ser utilizado, o que na maioria das vezes nao preve todos os casos
do mundo real.
Metodos formais (atraves de calculos matematicos) de testes de software sao amplamente propostos e muitas vezes mostram-se efetivos, mas sao apontados como tao
dificeis quanto a propria revisao do codigo.
Testes funcionais ainda assim sao necessarios, porque programadores ocasionalmente cometem erros em suas provas formais. Tambem porque tais metodos apenas demonstram que o software segue suas especificacoes, mas nao que este pode lidar com as surpresas do mundo real.
A engenharia de software precisa ser melhor abordada no mundo academico, para formar desde as universidades profissionais capacitados a projetar o software corretamente e levar-se em consideracao o re-uso de software.
Melhores praticas de re-uso tambem devem surgir, ja que mesmo as tecnologias atualmente existentes, como orientacao a componentes, ainda sofrem de dificuldades
de portabilidade em diversas situacoes e quando outras linguagens acabam sendo necessarias.
08/22/2006 - Comentários do artigo: "Operation Leadership" by Eli Cohen and Noel Tichy (in portuguese only, because I have no time to read, comment and then translate)
Solucoes criativas em situacoes ambiguas. Esta frase pode descrever o profissional do futuro, que todo tipo de organizacao necessita.
O artigo inicia fundamentando esta ideia com exemplos retirados das forcas especiais americanas, que cada vez mais enfrentam situacoes inusitadas de conflitos inesperados e sem previa determinacao ou informacoes adicionais, passando as decisoes para a frente de batalha e nao mais advindas de um comando central totalizador.
Diversas licoes podem ser aprendidas das forcas especiais americanas, e como eles mesmo dizem: "Nunca confunda entusiasmo com capacidade". Isto envolve saber do que se é capaz e ser capaz de se fazer o que se diz.
Ter as melhores pessoas é necessário para fazer coisas incríveis entao o processo seletivo precisa ser constante e bem elaborado, no caso, eles baseiam-se em príncipios fundamentais:
- Pessoas sao mais importantes do que "coisas"
- Qualidade é melhor do que quantidade
- "Pessoas excepcionais" (neste caso, os agentes das forcas especiais) nao podem ser "produzidas" (adequadamente identificadas e treinadas) em massa
- "Pessoas excepcionais" (neste caso, os agentes das forcas especiais) nao podem ser "produzidas" (adequadamente identificadas e treinadas) depois que a crise ocorre (este é o motivo da necessidade de constância)
Para identificar as pessoas corretas, sempre mostra-se necessário mecher na alta linha de comando (organizacional ou militar). Isto porque o método meritocrático comumente visto (e no artigo exemplificado militarmente) apresenta-se falho,
pois os "chefes" devem agora saber adequar-se a novos ambientes, novas situacoes e ter melhores capacidades de se adaptar e relacionar.
Torna-se fundamental para os negócios modernos ensinar as pessoas a pensarem, e
nao no que (ou como) pensarem.
As pessoas precisam entender que as ferramentas (e técnicas organizacionais em geral) devem ser vistas de um contexto mais geral e nao entendidas com um propósito específico.
Valores como tomar a iniciativa ao invés de esperar as decisoes virem de cima, nao contar com excecoes, tomar cuidado com a empolgacao (nem sempre as primeiras
informacoes recebidas sao as corretas e definitivas), experar o inesperado (se antecipar) e estar preparado para tudo sao essenciais no âmbito militar (para os
"super-soldados") mas também quesitos imprescindíveis para profissionais do futuro.
Essencialmente os líderes devem ter a capacidade de formar novos líderes e sua performance pode ser avaliada pelo comportamento de sua equipe em sua ausência (este comportamento deve ser equivalente ao de sua presenca).
08/15/2006 - Article: "A Business-Oriented Foundation for Service Orientation" by Ulrich Homann
Microsoft never stops to impression me! This article covers an important area that always miss in technical articles: The business itself, and how to modeling it.
Of course, as all we knows, when we talk about SOA, we are talking about open-standards, open-interfaces, well published connections, and so on... but, why the business really need it?
This article tries to cover this important question... the business really needs SOA?
The capability idea is really amazing... why not modeling the business acordingly what all business unit do (not how it does)?
Doing so, the author achieves automaticly the SOA idea in the business modeling... we have an external idea of the business, and how it connect with another units and to external elements.
Some new definitions from the article:
- Business capability: What a business unit do
- Capability connector: Connections existent between two or more capabilities
- Business processes: How a business unit implements a capability
- Business capability mapping: Is the complete structure of all capabilities and their connections
Because the actual view of the companies, when a process need to change, it affect many other portions of the company (it produces really difficult to change (and expensive) systems).
Using capabilities, all capability will export some interfaces... if the business processes conteined in this capability change, the capability itself does not change, preserving the ROI (return of investment).
The capabilities itself can be decomposed in levels. The author propose three levels:
- Foundation (level 1)
Address all the "ecosystem" of the business:
- What company offer to the market
- Who interact with the company (customers, providers, government, others...).
- Capability Groups (level 2)
The first abstraction of service levels, impediments and constraints. If company has a foundation capability like: "1. Offer Products/Services to the market", then will have a capability group like: "1.1. Plan Products/Services".
My conclusion: This article covers an important lack of information against IT and business modeling. It offers a good argument to use SOA and how to implement IT projects.
08/15/2006 - Ok, im revisiting some conferences materials
I have found a magazine who have covered the h2hc II and have an interview with me.
Also, here you will can see a television program who have made an interview
with me to h2hc II too
Is important to say these interviews are just pieces of a major interviews...
08/04/2006 - Experiences with digitalenterprise.org website
Ok guys, the first home-work of my post-graduation is to comment the digitalenterprise.org website...
Its a really great course about how to manage and deploy a web-based company. The company who wanna uses the internet as a way to have activities.
The best approach i have seen in the course is when talking about the risks. Not only the security-related risks (but it is really important to new companies and to old companies too, of course) understand about the security risks at the web.
But, the security risks is a technology question. You can use encryption, you can inform your users, you need to understand the fears against web-based commerce and so on.
The digitalenterprise.org course says about another risk, the problems with the already existing commercial channels. When you have direct sells under the internet, your company can be a concurrency of your own channel... its a real problem that the companies must understand.
I seen only one problem with the digitalenterprise.org course, it need to have a PDF version of all pages of the course, because one can download the pdf in the laptop to read later (i loved to seen some chapter have the pdf version).
Maybe the course can be more interactive, and have more links to interesting pages talking about some topics (like the security-related ones).
In any way, its a good website to visit and learning more about the new world companies.
08/04/2006 - Solaris Experiences
Well, im using solaris for some stuffs... under sparc and opteron (ia64) archs... its a interesting OS
To configure a virtual interface under solaris:
- ifconfig bge0:1 plumb
- ifconfig bge0:1 up
Where bge0 is my interface name
08/04/2006 - Bush visiting NSA exposes security systems
This is a dumb post, just because i dunno what to do with this picture... i dont want it im my computer and dont want to simply remove or forgot it
Click here to see the picture
See at the background... this picture exposes the security systems used in NSA, a symantec product. It seens to be a security problem? Or maybe not?
|