It is not known how the US government has determined that North Korea is the culprit, though it is known that the NSA has in the past penetrated North Korean computer systems.
Analysis of code shows it used knowledge of Sony's Windows network to spread and wreak havoc.
Previous analysis of the malware that brought down Sony Pictures' network showed that there were marked similarities to the tools used in last year's cyber-attack on South Korean media companies and the 2012 "Shamoon" attack on Saudi Aramco. While there was speculation that the "DarkSeoul" attack in South Korea was somehow connected to the North Korean regime, a firm link was never published."
Link to Original Source
Link to Original Source
Link to Original Source
I have tried a bunch of ways. Trained the 'expert' users in the area on how to put in a better ticket. Sent tickets back to them because of lack of information. Judicious of cattle prods and a tack hammer... However, users will use what method is easiest to them, which tends to be:
- Calling someone they know directly
- Emailing someone they know directly
- Emailing the ticket capture email address with 'Call me'
- Calling the service desk
- Screaming at someone from IS in the hallway
- Emailing the ticket capture email address with a long email chain which tangentally mentions the issue somewhere in the middle
- Complaining to coworkers
- not doing anything
- Log into the ticket system and put in 'call me'
We get shirts due to some organizational achievement. I pull them out of the closet around my annual review.
14 character, randomly generated passwords, changed monthly... all in my head. I use to tattoo them on girlfriends... but that didn't workout too well.
I thought it was 'what doesn't kill me cripples me for life'...
I find tfa pretty clueless when it comes a real understanding on what is needed for performance testing and tweaking. A statistical analysis is nice, especially with monte carlo type analysis, like Bungie running Halo 3 on numerious xboxs simulating load and player interactions. However, I find that what is lacking with programmers is a basic understanding on the high levels of process analysis, such as network analysis, CPM, and PERT. Knowing a process has high levels of variance is nice, but not useful for understanding the why. Where is Zed's example of multivariant linear regression or ordered probit? Discussion on hypothesis testing? Anyone, anyone?
As a side note, Statistics in a Nutshell is the only book programmers really need on stats.
Military. Twenty guys could take over Mountain View with some decent training.
I agree with your statement. IT does a bad job learning their customer's business. I think it has to do with the inherent IT ego. I work on some systems (Infor's SmartStream and BPA for example) where other customers can't believe that IT is so heavily involved in business process decisions. Many of our business process improvement projects are run by our systems department (were our IT project managers are) instead of the functional users. For a midcap organization, that seems to be unusual. (Observed phenomina that would make a good research article) However, it works for us.
Don't get me wrong, we still make spectacular screwups. Usually it is due to the lack of a rigourous project management methodology. I am the only person with the project management professional (PMP) certification and there is some resistance against my calls for a more formal process. (I don't want full PMI methodology, only an idiot wants to apply that willy nilly) Ends up that a good quarter to half of my projects start out as someone else's. It is my experience that the major issues tend to be lack of requirements analysis, cost control, and/or scope control being the major issues here. (Another observed phenomina that would make a good research article - should I start writing the problem statements for my fellow researcher too? Get busy) Better training and education would fix some of these issues.
Let me make a comparison. I and another analyst are working similar projects with a similar timeframe. He has worked here for a year after college. I have worked for ten. We have four weeks to finish the project. I finish mine in two weeks at about four hours a day, five days a week. He takes all four weeks, working ten hour days, seven days a week. The difference between us is really experience. I will spend my time up front learning my users wants and needs, while he works on the rock methodology of requirements analysis. (User: I want a rock. Analyst: Is this the rock you want? User: No, find a different rock. Goto Beginning.) I take time every week to network with my users and learn their business processes and what their problems are. My cohort just is to busy showing everyone how smart he is and how hard he works. That is why I read the WSJ, Slashdot, Wired, the Economist, some industry rags (our core business, not IT), and Tech Review at work. It helps for me to understand what my customer needs are, sometimes before they do. Design iterations are quicker and more complete solution wise. Trying to explain it to a fresh face out of college who has been taught just to code is very difficult.
You make a valid point. The discussion becomes what is private and what is not. Lets go to your example of pedophiles. First off, I agree with the bullet to the brainpan concept of handling pedophiles. However, I am think more of the implied children. My brother does not want pictures of his sons on the net while they are minors, especially when they are very young due to the preceived temptation it is to preditors. It is a valid point to encourgage better privacy. When we consider the number of complaints comming to light of Iran's intellegence services targeting expat dissidents, the argument becomes stronger. When we allow for information that can be sigificantly damaging to someone to become public domain, the World suffers in ways we might not anticipate.