Sugerir tradução
Outras sugestões:

progress indicator
Sem sugestões.
TechNet Magazine > Home > Todas as edições > 2009 > TechNet Magazine Março 2009 >  Localizando e corrigindo a causa raiz de proble...
Exibir Conteúdo: Lado a LadoExibir Conteúdo: Lado a Lado
Este é um conteúdo traduzido por máquina que os membros da comunidade podem editar. Incentivamos você a melhorar a tradução clicando no link Editar associado a qualquer sentença abaixo.
Desktop Files Mitigating Circumstances
Wes Miller

The term mitigate is defined generally as to "make less severe, serious, or painful." I've spent quite a bit of time in this column discussing technologies that can be used to mitigate problems, especially those related to security. Growing up, I learned many proverbs and parables that were meant to help reinforce good behavior—and I'm still a big believer in many of those lessons I learned. My favorite proverb is "An ounce of prevention is worth a pound of cure." And my favorite quote is by philosopher George Santayana: "Those who cannot remember the past are condemned to repeat it." Together these do a good job of expressing how I like to operate—and how I wish more technologies operated.
Unfortunately, you and I get to interact with technology at a level that most people don't get (have?) to. While this is great at forcing us to learn technology, all too often the technology doesn't behave the way it's supposed to behave. When that happens, we have to mitigate against it to ensure that further damage doesn't happen as a result of the failure.
This month, I'm going to take my column in a bit of a philosophical direction. Simply by reading the pages of TechNet Magazine, you've already proven yourself to be something of a technophile—so I may just be preaching to the people who already agree with me here. Still, the points I bring up in this month's column are important enough to underscore.
I've mentioned before that the technology I work on (security and whitelisting) is a bit more of a preventative than is the standard technology that's been used to deal with malware for the last 25 years, which essentially compiled blacklists of signatures of known malware. The preventative approach can be a pretty avant-garde road to go down. But as I said in my November column (" Data Loss Prevention with Enterprise Rights Management "), it's all about what your real goal is. If you come into a conversation saying "I want to stop malware" without exploring other approaches, you'll simply follow the standard "find the bad stuff and eliminate it" path. You can see how easily this can become the norm—without ever really solving the problem.
Instead of that standard approach, I prefer the more pragmatic "What is the real problem that I'm trying to solve?" In this column, I'm going to discuss why I think this is useful. I'll look at a few random events, incidents, and technology problems, and show how the wrong approach is taken way too often as a reaction to them.

I Love YOu
Where were you on May 4, 2000? I worked at—and all of a sudden, everyone loved me. It was the dawn of iloveyou.vbs. This little malware gem took advantage of three conditions to spread virally.
First, the malware used social engineering to get users to open the message. It came from someone you knew (you had to be in the sender's address book in order for it to be sent), so of course you had to find out if you were really loved.
Second, it was based upon the fundamentally correct notions that users a) don't know diddly about file extensions; b) don't bother to check file extensions (heck, they're hidden by default in Windows); and c) will click past anything warning them of potential badness (to see the dancing pigs, as Steve Riley likes to say). See Steve's blog, Steve Riley on Security , for more information.
Third, it took advantage of a fundamental architectural flaw, a flaw so apparent it should have been caught before the product with the flaw shipped. But it wasn't caught—so the malware could intrude and then spread very rapidly. ILOVEYOU worked by running Windows Script Host, harvesting the user's address book, and then sending e-mail to everyone in the victim's address book. As long as those in the address book also ran Microsoft Office Outlook on Windows and fell for the social engineering component of the virus, the process continued.
So where was the flaw? C'mon, give it a guess. Ready? The flaw was in Outlook, caused by two fundamental problems. When Outlook was originally designed, as with Internet Explorer 3.0 before it, COM and ActiveX were becoming all the rage—so you could quickly and easily reuse components of one application in another. Outlook, however, was far too trusting regarding who could call its COM object model. Inbound, completely unsecured documents—let alone e-mail content—should never have been able to even look in the address book, much less harvest it completely and then send e-mail. Sure, there are scenarios where it makes sense for an incoming e-mail to automatically send an e-mail response. But that's the exception—far from the rule.
Security in Outlook was subsequently tightened so that it now asks users when an application wants to query the address book or programmatically send mail (see Customize Programmatic Settings in Outlook 2007 ). That was an important step in the right direction. Users are also asked whether they want to grant permissions for the application—because, frankly, we all know what happens if a user really wants to see those dancing pigs.
You know what the mitigation most likely to be put in place was while users waited for Outlook to be fixed? Killing Windows Script Host (WSH). Beginning in 2000, like no other time in my career, one of the most frequent questions I got was, "My customer wants to remove WSH from Windows—how can this be done?" What a sorry state—an incredibly powerful scripting language was threatened due to drive-by malware that was enabled by security flaws.
I am, of course, a big fan of WSH. I think it's a great tool and that Windows PowerShell actually has a ways to go before it can replace WSH (though that's another column topic for another day). But my point is that WSH in and of itself is not a security hole. Eliminating one component because of the flaws in another is not an effective way to manage things. Still, it is very important that you secure your operating system, Web browser, and e-mail client (especially if it is COM enabled—ahem) to ensure that they cannot take advantage of WSH in a negative way.

King COM
In 1994, Microsoft released ActiveX, and the world seemed to take two opposing views: it was pure evil and would cause the downfall of the Internet, or it was a great, powerful tool and would make the browser into a real platform. ActiveX in and of itself is not a huge exploit waiting to happen. In fact, Microsoft did a pretty good job of implementing security for ActiveX in Internet Explorer—though, of course, it has been further hardened over the years as the rest of Windows has.
Nevertheless, one of my favorite Web searches is "2008 buffer overflow ActiveX." Go ahead—try it. You can change the year, if you like, to see how each year has gone. Why do I find this interesting? It's because Internet Explorer and ActiveX controls have unfortunately become the poster children for security vulnerabilities, deserved or not.
We face somewhat similar problems in the world of whitelisting software. Sure you can try to secure a system by only allowing code to run that's already on the PC, but suppose there are exploits in that code? You can get owned just as well as if you had no security software on the system. Just as with buffer overflows, controls that have wrongly been marked as "Safe for Scripting" become giant holes for hackers to take advantage of.
Why do I bring up the buffer overflow aspect here? Because this problem generated a response similar to the WSH/Outlook behavior noted earlier. Instead of blame attaching to vendors for not performing decent threat modeling and buffer-overflow detection and for incorrectly marking a control as Safe for Scripting, ActiveX itself became the culprit.
Perhaps it's fair. If Microsoft had implemented a better sandbox (as has been done to a degree in Windows Vista via Protected Mode) or if Microsoft had simply not allowed Safe for Scripting, we would not have these problems. And ActiveX would probably be more widely spread—or at least more widely tolerated.
Unfortunately, we do have these problems—and the ActiveX kill-bit (see Figure 1) has become something with which admins are all too familiar. See " How to stop an ActiveX control from running in Internet Explorer " for a description of how to programmatically kill any ActiveX control that is perceived as a threat. Controls check this registry entry before instantiation to see if they are allowed to run.
Figure 1 You can prevent an ActiveX control from running by setting the killbit so that the control is not called by Internet Explorer
The reality is that if you want to perform certain tasks from within Internet Explorer, such as querying a registry key, interacting with hardware or another application, or interacting with user data on a Windows PC, you basically have no choice except an ActiveX control. And creating a control—properly designed, threat modeled, developed, tested, and signed (whew)—can be a rather foreboding task. But it honestly shouldn't be viewed as a bad thing or as a giant security hole (unless you skip or short-circuit those steps). Oh, and about Safe for Scripting—if you're developing a control, and you have to have it safe for scripting, don't. Really. Not unless you have no other choice.
That said, how do you mitigate against bad ActiveX controls? The fans of other browsers will gleefully tell you "My browser doesn't have those kinds of exploits," but that's naive. Internet Explorer on Windows is designed very well, but it has flaws. All software has flaws. Running Web browser B because you believe Web browser A has flaws is usually grounded in zeal—not in actual security. There have been security flaws found in every major browser and in every major ActiveX control. The answer?
The upshot is that though you can disable ActiveX controls to the point that they won't run (see Figure 2), there will still be exploits—even if you use another Web browser. You need to learn the attack surface of whatever software you do decide to run. Simply avoiding Internet Explorer doesn't make you malware proof; it just makes you resistant to malware that targets Internet Explorer.
Figure 2 Managing ActiveX controls in Internet Explorer

The Flash Drive Dilemma
Many customers have huge concerns about USB flash drives, more so than almost any other technology. Why? When I talk to our customers, it comes down to two issues. First, USB flash drives are easy targets for social engineering, or any other means, trying to get malware onto computers (this really applies to targeted malware, the kind that traditional audio visual software can't catch until it's too late). Second, it is all too easy for sensitive data to walk out of the office on a tiny USB drive. That's why I'm such a big fan of Information Rights Management (IRM) and other Digital Rights Management (DRM) techniques that can truly prevent data loss. Clearly the real problem is not the USB flash drive itself; it's the way these drives can be used.
So rather than using epoxy to glue the USB ports shut (I've actually heard of that being done) or trying to block the hardware via Group Policy or third-party software, what can you do? Stopping targeted malware is difficult, something you can really only approach via Group Policy Software Restriction Policies, whitelisting, or other means of restricting code to run only from the system drive, network drive, or the like.
As for stopping data loss, that will probably involve some form of IRM/DRM. Still, anytime I have to talk to customers about USB flash drives (or any type of malware, for that matter) I tend to quote my first TechNet Magazine article (" Reduce Your Risk: 10 Security Rules To Live By "), "Your enterprise is only as secure as your least and most technical users." By that I mean that an end user who really wants to run a piece of software will find a way, just as an end user who really wants to share confidential information will also find a way to do so.

What's the Point?
Years ago, when I worked at Winternals, Mark Russinovich researched and blogged on three topics pertinent to this discussion: defeating Group Policy (both as an administrator and as a limited user) and elevating privileges as a power user.
The "Mark Russinovich on Security" sidebar will direct you to the blog posts. These are great examples that demonstrate just how easy it is for a user to break free of policy or security constraints. Frustrated users often react to being locked down by eventually being willing to violate constraints—whether software, hardware, or policy based.
The three issues referenced in the sidebar have been concerns for some time. They are representative of the kinds of problems we all have to work around in our daily lives in a Windows ecosystem. The trouble is that mitigating against vulnerabilities, flaws, and software imperfections requires more than just reaction. It requires pragmatic thought about the real problem, which usually involves a good grasp of threat modeling and a willingness to accept that short-circuiting the immediate issue may cause a bigger fire than if you dealt with the real problem from the beginning.
A much better idea is to approach every situation with an open mind and, knowing that there are problems against which you are going to have to mitigate, take a step back and think about what the root problem actually is instead of just reacting in a short-sighted manner.

Wes Miller is a Senior Technical Product Manager at CoreTrace in Austin, Texas. Previously, he worked at Winternals Software and as a Program Manager at Microsoft. Wes can be reached at .

Arquivos da área de trabalho Atenuantes circunstâncias
Wes Miller

O termo atenuar geralmente definido como para "fazer menos graves, grave ou doloroso." Passei um pouco de tempo desta coluna discutindo as tecnologias que podem ser usadas para mitigar os problemas, especialmente aqueles relacionados à segurança. Enquanto crescia, eu aprendi muitos provérbios e parábolas que se destinavam a ajudar a reforçar o bom comportamento - e eu ainda acredito em muitas dessas lições que aprendi. Meu provérbio favorito é "Um grama de prevenção é melhor que um quilo de cura". E minha citação favorita é do filósofo George Santayana: " Aqueles que não se lembram do passado estão condenados a repeti-lo." Juntos, eles fazem um bom trabalho de expressar como eu gosto de operar — e como eu gostaria que mais tecnologias operassem.
Infelizmente, você e eu temos que interagir com a tecnologia num nível em que a maioria das pessoas não podem (devem?). Embora isso seja ótimo para forçar-nos a aprender tecnologia, muitas vezes a tecnologia não se comporta da forma que deveria se comportar. Quando isso acontece, temos de atenuar as ameaças para garantir que mais danos não aconteçam como resultado da falha.
Este mês, vou levar minha coluna numa direção um pouco filosófica. Simplesmente lendo as páginas do revista TechNet, você já provou a si mesmo que é um tanto tecnófilo — então pode ser que eu esteja apenas pregando para pessoas que já concordam comigo aqui. Ainda assim, as questões que trago na coluna desse mês são importantes o suficientes para serem destacadas.
Já mencionei antes que a tecnologia na qual trabalho (Segurança e whitelisting) é um pouco mais preventiva do que a tecnologia padrão que foi usada para lidar com malware nos últimos 25 anos, que essencialmente compilava listas negras (blacklists) de assinaturas de malwares conhecidos. A abordagem preventiva pode ser uma estrada bastante vanguardista a se seguir. Mas como eu disse em minha coluna de novembro " Prevenção da perda de dados com o gerenciamento de direitos empresariais "), é tudo sobre qual é o seu objetivo real. Se você entrar em uma conversa dizendo "Quero acabar com o malware" sem explorar outras abordagens, você simplesmente irá seguir o caminho padrão de "encontrar as coisas ruins e eliminá-las". Você pode ver como isso pode facilmente se tornar a norma — sem nunca realmente solucionar o problema.
Em vez dessa abordagem padrão, eu prefiro a forma mais pragmática "Qual é o problema real que estou tentando resolver?". Nesta coluna, vou discutir por que eu acho que isso é útil. Eu examinarei alguns eventos aleatórios, incidentes e problemas de tecnologia, e mostrarei como a abordagem incorreta é utilizada muito freqüentemente como reação aos mesmos.

Eu te amo
Onde você estava em 4 de maio de 2000? Eu trabalhava na—e de repente, todos me amavam. Era o despertar do iloveyou.vbs. Esse pequeno malware aproveitou-se de três condições para espalhar-se viralmente.
Em primeiro lugar, o malware usou engenharia social para fazer com que os usuários abrissem a mensagem. Chegou de alguém que você conhecia (você tinha que estar no catálogo de endereços do remetente para que ela fosse enviada), então obviamente você tinha que descobrir se era realmente amado.
Em segundo lugar, ele foi com base nas noções fundamentalmente corretas que os usuários a) não sabem absolutamente nada sobre extensões de arquivo; b) não se preocupam em verificar as extensões de arquivo (ora, estão ocultas por padrão no Windows); e c) vão ignorar todos os avisos de risco em potencial (para ver os porcos dançarinos, como Steve Riley gosta de dizer). Consulte o blog do Steve, Steve Riley sobre segurança , para mais informações.
Em terceiro lugar, ele aproveitou uma falha de arquitetura básica, uma falha tão aparente, que ela deveria ter sido detectada antes do produto com a falha ser fornecido. Mas ela não foi detectada — então o malware pôde invadir e se espalhar muito rapidamente. O ILOVEYOU trabalhava executando o Windows Script Host, coletando o catálogo de endereços do usuário e, em seguida, enviando emails para todos no catálogo de endereços da vítima. Desde que aqueles que estivessem no catálogo de endereços também rodassem o Microsoft Office Outlook no Windows e caíssem no componente de engenharia social do vírus, o processo continuava.
Então, aonde era a falha? Ora, tente adivinhar. Está pronto? A falha era no Outlook, causada por dois problemas fundamentais. Quando o Outlook foi originalmente projetado, assim como o Internet Explorer 3.0 foi, COM e ActiveX estavam se tornando tornando um furor — então você poderia rápida e facilmente reutilizar componentes de uma aplicação em outra. O Outlook, entanto, foi muito confiante em relação a quem poderia chamar seu modelo de objeto COM. Documentos que chegassem totalmente desprotegidos — o que dizer do conteúdo do email — nunca deveriam ser capazes de sequer examinar o catálogo de endereços, muito menos coletá-lo completamente e, em seguida, enviar emails. Claro, existem cenários onde faz sentido para um email de entrada enviar automaticamente um email de resposta. Mas essa é a exceção — longe da regra.
A segurança no Outlook foi subseqüentemente reforçada para que ele agora consulte os usuários quando um aplicativo deseja consultar o catálogo de endereços ou automaticamente enviar emails (consulte Personalizar configurações de programação do Outlook 2007 ). Isso foi um passo importante na direção certa. Os usuários também são questionados se eles desejam conceder permissões para o aplicativo - porque, francamente, todos nós sabemos o que acontece se um usuário realmente deseja ver esses "porcos dançarinos".
Você sabe qual foi o paliativo mais provável de ser colocado em prática enquanto os usuários esperavam o Outlook ser corrigido? Matar o Windows Script Host (WSH). No começo de 2000, como em nenhum outro período na minha carreira, uma das perguntas mais freqüentes que obtive foi, "Meu cliente deseja remover o WSH do Windows, como isso pode ser feito?" Que estado lastimável, uma linguagem de script incrivelmente poderosa foi ameaçada devido a um malware direcionado que estava habilitado devido a falhas de segurança.
Eu sou, obviamente, um grande fã do WSH. Eu acho que é uma excelente ferramenta e que o Windows PowerShell atualmente pode acabar antes que ele venha a substituir o WSH (apesar de que este é outro tópico da coluna para outra hora). Mas meu ponto é que o WSH em si não é uma brecha de segurança. Eliminar um componente devido as falhas em outro não é uma maneira eficiente de gerenciar itens. Ainda assim, é muito importante que você proteja o sistema operacional, o navegador da Web e o cliente de email (especialmente se estiver com o COM habilitado, claro) para garantir que não é possível tirar proveito do WSH de maneira negativa.

Em 1994, a Microsoft lançou o ActiveX e o mundo parecia ter tomado dois pontos de vista opostos: ele era mal puro e poderia causar a queda da Internet, ou ele era uma ferramenta excelente e poderosa que tornaria o navegador em uma plataforma real. O ActiveX em si não é um grande exploit aguardando para acontecer. Na verdade, a Microsoft fez um trabalho muito bom implementando a segurança para o ActiveX no Internet Explorer - no entanto, claro, ele tem sido ainda mais protegido com o passar dos anos assim como o restante do Windows.
No entanto, uma das minhas pesquisas da Web favoritas é "2008 buffer overflow ActiveX." Vá em frente, experimente. Você pode alterar o ano, se desejar, para ver como foi em cada ano. Por que acho isso interessante? É porque o Internet Explorer e os controles ActiveX infelizmente tornaram-se a menina dos olhos das vulnerabilidades de segurança, merecendo ou não.
Enfrentamos problemas um pouco semelhantes no mundo do software whitelisting. Claro que você pode tentar proteger um sistema permitindo apenas a execução de código que já está no PC, mas e se houverem exploits nesse código? Você pode ser invadido tão fácil como se não tivesse nenhum software de segurança no sistema. Assim como com estouros de buffer, controles que incorretamente foram marcados como "seguro para scripts" serão buracos gigantes para que hackers aproveitem.
Por que trazer o aspecto de estouro de buffer pra cá? Porque esse problema gerou uma resposta semelhante ao comportamento do WSH/Outlook observado anteriormente. Em vez de blame anexar a fornecedores para não executar detecção de modelagem e estouro de buffer de ameaça decente e incorretamente marcando um controle como seguro para scripts, ActiveX se tornou-se o culpado.
Talvez é razoável. Se o Microsoft tinha implementado uma proteção melhor (como foi feito em um grau no Windows Vista por meio do modo protegido) ou se Microsoft tinha simplesmente não permitido seguro para scripts, nós não teria esses problemas. E espalhar ActiveX seria provavelmente mais amplamente se — ou pelo menos mais amplamente tolerated.
Infelizmente, temos esses problemas — e o bit de eliminação ActiveX (veja a Figura 1 ) tornou algo com que administradores são muito familiarizados. Consulte" Como parar um controle ActiveX seja executado no Internet Explorer "para obter uma descrição das como programaticamente eliminar qualquer controle ActiveX que é percebida como uma ameaça. Controles verificar essa entrada do Registro antes de instanciação para ver se eles podem ser executados.
Figura 1 você pode impedir que um controle ActiveX seja executado, definindo o killbit para que o controle não seja chamado pelo Internet Explorer
A realidade é que, se desejar executar determinadas tarefas de dentro do Internet Explorer, como consultar uma chave de registro, interagir com o hardware ou em outro aplicativo, ou não interagir com dados do usuário em um PC do Windows, basicamente que nenhuma opção, exceto de um controle ActiveX. E criar um controle — projetados, ameaça modelado, desenvolvidos, testados e assinado (Uau) — pode ser uma tarefa foreboding em vez disso. Mas ele Honestamente não deve ser exibido como algo ruim ou como uma brecha de segurança giant (a menos que você ignorar ou curto-circuito essas etapas). AH e sobre como seguro para script — se você está desenvolvendo um controle, e você precisará fazer com que ele seguro para script, não. Na verdade. Não, a menos que você tenha nenhuma outra opção.
Dito isso, como atenuar contra incorretos controles ActiveX? Os fãs de outros navegadores gleefully informará "Meu navegador não tiver esses tipos de explorações", mas isso naive. Internet Explorer no Windows foi projetado muito bem, mas ele apresenta falhas. Todos os softwares tem falhas. Executando o navegador da Web B porque você acredita navegador A apresenta falhas normalmente com aterramento em zeal — não na segurança real. Houve falhas de segurança encontradas em cada navegador principal e em cada controle ActiveX principal. A resposta?
O upshot é que embora você pode desativar os controles ActiveX o ponto de que eles não serão executados (veja a Figura 2 ), será ainda haver explorações — mesmo se você utilizar outro navegador da Web. Você precisa saber a superfície de ataque de qualquer software que você decidir executar. Simplesmente evitar o Internet Explorer não faz você prova de malware; ele apenas torna você resistente a malwares que destinos do Internet Explorer.
A Figura 2 gerenciamento ActiveX no Internet Explorer

A dilema unidade flash
Muitos clientes estiver enorme preocupado com as unidades flash USB, portanto, mais do que quase qualquer outra tecnologia. Por quê? Quando falarei para nossos clientes, ele vem até dois problemas. Primeiro, as unidades flash USB são alvos fáceis de engenharia social, ou outros meios, tentar obter malware em computadores (isso realmente se aplica a malware de destino, o tipo que tradicional software visual áudio não pode capturar até que ele é muito tarde). Em segundo lugar, é tudo muito fácil para dados confidenciais movimentar fora do escritório em uma pequena unidade USB. Que é por que eu sou um fã grande de IRM (gerenciamento de direitos de informações e outras técnicas de gerenciamento de direitos digitais (DRM) que podem realmente evitar a perda de dados. Claramente o problema real não é a unidade flash USB propriamente dito; essa é a maneira que essas unidades podem ser usadas.
Portanto, em vez de usar epoxy para colar o USB portas desligamento (na verdade, ouvi do que seja feito) ou tentar bloquear o hardware por meio de diretiva de grupo ou um software de terceiros, o que pode fazer? Interromper o malware de destino é difícil, algo pode realmente abordagem somente por meio de diretivas de restrição de software de diretiva de grupo, whitelisting ou outros meios de restringir o código para executar a somente a partir da unidade do sistema, unidade de rede ou similares.
Para interromper a perda de dados, que provavelmente envolverá alguma forma de IRM/DRM. Ainda assim, sempre que TENHO que conversar com os clientes sobre USB unidades flash (ou qualquer tipo de malware, nisso) tendem a cotação meu primeiro artigo TechNet Magazine " Reduzir O risco: 10 regras de segurança para o Live por "), "Sua empresa só é tão segura como os usuários técnicos pelo menos e a maioria dos." Por que QUERO dizer que um usuário final que realmente deseja executar uma parte do software encontrarão uma maneira, assim como um usuário final que realmente deseja compartilhar informações confidenciais também encontrarão uma maneira fazê-lo.

O que é o ponto?
Anos atrás, quando trabalhou na Winternals, Mark Russinovich pesquisadas e publicou no blog anteriormente nos três tópicos relevantes para essa discussão: invalidando a diretiva de grupo (tanto como um administrador como usuário limitado) e elevar privilégios como um usuário avançado.
A barra lateral "Mark Russinovich em segurança" direcionará você para as postagens de blog. Estes são exemplos excelentes que demonstram como é fácil para um usuário quebrar sem restrições de diretiva ou segurança. Usuários frustrados geralmente reagem a que está sendo bloqueado por, eventualmente, sendo dispostas a violar restrições — se software, hardware ou diretiva baseada.
Os três problemas mencionados na barra lateral foram preocupações de algum tempo. Eles são representa os tipos de problemas que todos nós tem que trabalhar em torno em nossas vidas diárias em um ecossistema do Windows. O problema é que mitigação contra as vulnerabilidades, falhas e imperfections de software requer que mais do que apenas reação. Ele requer pragmatic pensou sobre o problema real, que geralmente envolve um bom entendimento de modelagem de ameaças e uma disposição para aceitar que short-circuiting o problema imediato pode causar um incêndio maior do que se você lidado com o verdadeiro problema desde o início.
Uma idéia muito melhor é abordar cada situação com uma mente aberta e, saber o que há problemas em que for necessário reduzir, executar uma etapa fazer e considerado sobre a raiz problema, na verdade, em vez de apenas reagir de maneira cego curto.

Wes Miller é técnico do gerente sênior em CoreTrace em Austin, Texas. Anteriormente, ele trabalhou na Winternals Software e como gerente de programas da Microsoft. Wes pode ser contatado pelo .

Page view tracker