Introducing TAuth: Why OAuth 2.0 is bad for banking APIs and how we're fixing it

https://blog.teller.io/



"One of the biggest problems with OAuth 2.0 is that it delegates all security concerns to TLS but only the client authenticates the server (via it's SSL certificate), the server does not authenticate the client. This means the server has no way of knowing who is actually sending the request. Is it a bona fide user, or is an attacker tampering with the request? When an attacker is able to insinuate themselves between a legitimate user and the server, it's called a man-in-the-middle (MITM) attack. 



It looks like this:

client attempts to connect to service
attacker successfully reroutes traffic to a host it controls
malicious host accepts connection from client
malicious host connects to service
service accepts connection from malicious host
client communicates with service proxied through malicious host, which can see and tamper with any data sent or received 


You're probably thinking "hang on, isn't this the point of SSL?" Yes it is, but there are a number of ways to present a bogus certificate and a client accept it. The most realistic threat is the client developer not properly verifying the server certificate, i.e. was it ultimately signed by a trusted certificate authority?

Unfortunately a large number of developers think that disabling SSL peer verification is the correct fix to a SSL path validation error. There are many more that will offer the same advice with the caveat that it introduces a security issue that < 100% of readers will consider. As an API provider with a duty of care to our users we can't simply hope developers on our platform don't do this."



'via Blog this'

comparethecloud: What exactly is hybrid cloud: A stepping stone, a sanctuary for regulated industries or a rampart for old tech vendors? -

What exactly is hybrid cloud: A stepping stone, a sanctuary for regulated industries or a rampart for old tech vendors? -:



So what’s stopping everyone moving to public cloud?

One old expression still holds true: “Why do people rob banks? Because that’s where the money is!”


The fact that the banks remain the main target for hackers and cybercriminals of all kinds means that a heightened level of security is essential. Some time ago banks were described as simply technology companies with a banking licence, because everything they did was already digitised. It might be more accurate to describe them as security companies, because everything they do is based on trust, if their security is compromised and trust is lost, a bank is out of business.


This is not to argue that private environments always have lower latency and higher security then public ones, but whatever level of regulatory certification AWS, Azure and Google obtain, the banks are going to want to be hyper secure.

Whatever level of regulatory certification vendors obtain, the banks are going to want to be hyper secure.CLICK TO TWEET

After all, while AWS beat all the competition (IBM included) to win the CIA’s business, the CIA doesn’t use the main AWS cloud facilities. Instead it uses an especially secure private cloud provided by Amazon. Should the banks settle for anything less?

Why the Linux Mint hack is an indicator of a larger problem - TechRepublic

Why the Linux Mint hack is an indicator of a larger problem - TechRepublic:

While these attacks are regrettable, and part of an infrastructure problem rather than a problem with the distribution itself, it increasingly appears that the Linux Mint team, led by project leader Clement Lefebvre, is spread too thin when it comes to security.

The architectural design of Linux Mint inherits a great deal from its upstream sources Debian and Ubuntu (which is itself based upon Debian). Unfortunately, it lacks any sort of security advisories—Linux Mint evangelists insist that referring to the Ubuntu or Debian advisories is sufficient. Not every package in Linux Mint is available in Ubuntu or Debian, and this argument is further complicated by the fact that updates that work perfectly in Ubuntu or Debian are blacklisted by the Linux Mint team due to compatibility issues.

Linux Mint has the somewhat peculiar design decision of not updating the kernel using the graphical update manager. Users must run apt-get dist-upgrade in a terminal in order to receive updates, when users of Ubuntu receive the same kernel updates automatically. This leaves users vulnerable to potential root exploits and hardware issues. Additionally, there is an issue with shifting release cadences—with version 17, the underlying base moved from standard releases to Long-Term Support (LTS) releases of Ubuntu. Consequently, the packages incorporated are older, on average, than in previous releases, and if blacklisted are both old and insecure.

Software Security links

Does DevOps hurt or help security?



While security processes tests always should be an integral part of DevOps workflow, that isn’t a reality for many organizations. They’ve always struggled to properly integrate security, and those challenges certainly persist through transitions to DevOps. But Storms says that DevOps provides an opportunity to more tightly couple security into the workflow. “One of the best ways to bring DevOps and security together is to utilize the tools and the processes that DevOps really excels at and apply them to security,” he says — “things like automation, orchestration, and instrumentation. Let's use those tools to build these closed-loop security systems where everything's automated and everything's predictable. That’s a way we actually can fulfill the security requirements in an automated fashion with fewer resources.”

One success story that Storms cites is a healthcare company in the Northeast. “It has had serious compliance and security requirements so it performs continuous deployment. The company has extensively automated its security and compliance tests and the auditors are happy,” he says.