We live in a technological moment comparable to the early days of the Internet, which sparked fascination — and even some apocalyptic predictions and fears — when it first appeared. Today, we can all see that the Internet is such a natural part of our everyday lives that we only notice its existence when it’s missing. I’m betting my career that the same will soon happen with AI. But for companies to benefit from this disruption, they have to stop focus on the technology itself and see it as an amplifier of the value that can be offered to customers, which is at the heart of business strategies. Many of the discussions about Artificial Intelligence in teams, departments, and companies today still start with the question, “What data do we have, and what technology do we need to work with it?” Please don’t do that anymore! It’s time to turn the tables and look at what the customers’ needs are. What are the questions your customers are asking that, when answered, will generate value for them and the business? Only when you have this clarity you should start looking for the correct data and related AI applications.
Unlike ransomware, which must penetrate IT systems before it can wreak havoc, DDoS attacks appeal to cybercriminals because they're a more convenient IT weapon since they don't have to get around multiple security layers to produce the desired ill effects. The FBI has warned that more DDoS attacks are employing amplification techniques to target US organizations after noting a surge in attack attempts after February 2020. The warnings came after other reports of high-profile DDoS attacks. In February, for example, the largest known DDoS attack was aimed at Amazon Web Services. The company's infrastructure was slammed with a jaw-dropping 2.3 Tb/s — or 20.6 million requests per second — assault, Amazon reported. The US Cybersecurity and Infrastructure Security Agency (CISA) also acknowledged the global threat of DDoS attacks. Similarly, in November, New Zealand cybersecurity organization CertNZ issued an alert about emails sent to financial firms that threatened a DDoS attack unless a ransom was paid. Predominantly, cybercriminals are just after money.
For larger networks, consider using a map-based Wi-Fi surveying tool such as those from AirMagnet, Ekahau or TamoGraph during deployment and for periodic checks. Along with capturing Wi-Fi signals, these tools enable you to run a full RF spectrum scan to look for non-Wi-Fi interference as well. For ongoing interference monitoring, use any functionality built into the APs that will alert you to rogue APs and/or other interference. Map-based Wi-Fi surveying tools usually offer some automated channel analysis and planning features. However, if you're doing a survey on a smaller network with a simple Wi-Fi stumbler, you'll have to manually create a channel plan. Start assigning channels to APs on the outer edges of your coverage area first, as that’s where interference from neighboring wireless networks is most likely to be. Then work your way into the middle, where it’s more likely that co-interference from your own APs is the problem. ... If you have more than one SSID configured on the APs, keep in mind that each virtual wireless network must broadcast separate beacons and management packets. This consumes more airtime, so use multiple SSIDs sparingly.
The key here is usefulness and empowerment. If the process is useful, accurate and easy to interrupt, and the team is empowered to optimize, then it will naturally get shortened. Developers will want to run useful validations more often, earlier in the cycle. Take the example of regression tests that are tests owned by another siloed team, that are flaky, slow, run out of cycle and hard to figure out what is wrong in them. It is unlikely that they will get optimized, because the developers don’t perceive much value in them; whereas with a test suite based on the test pyramid that is owned by the team, is in the same code base, and is the gate to deployment to all environments, the team will come up with ways of improvement. You can apply the concept of feed loops to different scales, for example, super small loops, e.g. when the developer is coding, what feedback can we give them to help and nudge them? How does your IDE inform you have made a mistake, or how does it help you find the syntax for the command you are looking for? When we look at the developer flow, discovering information is a big source of friction.
Another issue is that technical interviews aren't standardized, meaning they can vary wildly from company to company – making it almost impossible for candidates to prepare fully. As a result, their fate rests largely in the hands of whoever is carrying out the interview on that day. "The interviews typically are not well thought out and not structured," says Tigran Sloyan, co-founder and CEO of assessment platform CodeSignal. "What typically happens is, you have a developer whose job it is to evaluate this person. Most developers don't have either practice or understanding of what it means to conduct a structured interview." When there's so much variability, biases begin making their way into the process, says Sloyan. "Where there's lack of structure, there is more bias, and what ends up happening is if whoever you're interviewing looks like you and talks like you, you [the interviewer] start giving them more hints, you start leading them down the right paths." The reverse is also true, Sloyan says. "If they don't look like you and talk like you, you might throw them a couple more curveballs, and then good luck making it through that process."
While automation is the use of advanced technologies to replace humans in low-value, repetitive, and tedious tasks with the goal of increasing profitability and lowering operating costs. It benefits businesses by allowing them more flexibility in how they operate and by increasing employee productivity by automating the most time-consuming and repetitive tasks so that employees can focus on more important tasks. In practice, the objective is to improve workflows and processes. Alex Kwiatkowski is principal industry consultant for financial services at UK-based SAS. He points out that banks are constantly seeking efficiency gains. Firms have long sought to remove time-consuming, and occasionally error-prone, manual tasks in favor of technology-infused, straight-through processing in the front, middle and back offices. More than just fanciful hyperbole, automation has proven an enabler to achieving such goals. No matter the bank, there's always room for improvement. Keep in mind, too, that these advances need not be giant leaps forward but are often the aggregation of marginal gains, if you will.
Like other gangs that operate modern ransomware codes, such as Sodinokibi and Maze, DarkSide blends crypto-locking data with data exfiltration and extortion. If they are not initially paid for a decryption key, the attackers threaten to publish confidential data they stole from the victim and post it on their dedicated website, DarkSide Leaks, for at least 6 months. When a ransom note appears on an encrypted networked device, the note also communicates a TOR URL to a page called “Your personal leak page” as part of the threat that if the ransom is not paid, data will be uploaded to that URL. Ransom is demanded in Bitcoin or Monero. If it is not paid by a specific initial deadline, the amount doubles. ... Most ransomware operators understand that they need speed to encrypt as much data as possible as quickly as they can. They, therefore, opt to use symmetric encryption for that first phase and then encrypt the first key with an asymmetric key. In DarkSide’s case, they claim to have come up with an accelerated implementation; the malware uses the Salsa20 stream cipher to encrypt victim data.
Reducing, or transforming a failure detector algorithm with one set of completeness and accuracy properties into a failure detector algorithm with another set of such properties means finding a reduction or transformation algorithm that can complement the original failure detection algorithm and guarantee that it will behave the same way as the target failure detection algorithm in the same environment given the same failure patterns. This concept is formally called reducibility of failure detectors. Because in reality it can be difficult to implement strongly complete failure detectors in asynchronous systems, per T.D. Chandra and S. Toueg we can transform failure detectors with weak completeness class into failure detectors with strong completeness. This concept is formally called reducibility of failure detectors. We can say that the original failure detector algorithm based on timeouts (described earlier) was reduced or transformed into an Eventually Weak Failure Detector by using increasing timeouts. As T.D. Chandra and S. Toueg showed that it is also possible to transform failure detectors with weak completeness into failure detectors with strong completeness.
As CIOs look to pivot to this new and more complete approach to building resilience, they will be coming from different places in the journey depending on their existing business strategy and investments. The good news is that this journey does not need to be undertaken in one swoop. CIOs can start with the quick wins, such as identifying and deploying the right collaboration tools, before moving on to longer-term processes, such as how best to migrate applications to the cloud and embrace cloud-native models. The starting point should be a resilience roadmap so you can plan when best to address the various dimensions of your strategy. This needs to be supported by a focus on your people to ensure they are able to leverage new technologies to their fullest and understand how to thrive in their work no matter where they are. Identifying what needs to change and putting in place an effective resilience strategy is now a critical business differentiator. In the past, business resilience was about doing the best in tough times, and often CIOs’ focus was on robust oversight and control to ensure that there were security breaches while business-as-usual was disrupted.
Knowing where an organisation’s data resides, who owns that data and what type of data it is, will ease any security incident and any legal or compliance implications. It will also ease an organisation’s ability to manage risk and improve their response over time. Commenting on the importance of knowing your data, William Klusovsky, Global Cybersecurity Strategy, Governance, Risk & Compliance Offering Lead at Avanade, said: “Often, technology leaders will forget that asset management is not just about keeping track of hardware, it means knowing where your data is, where your data flows and who owns that data.” The challenge of having a holistic view of an organisation’s data landscape is intensified by the problem of Shadow IT — the procurement of software and tech without IT’s knowledge. As new systems and applications are onboarded by various departments it’s easy to lose track of these, and what data sits within them, without a strong systems acquisition process. With healthcare specifically, the rapid introduction of IoT medical devices and all the new data they’re generating, exemplifies this.
Quote for the day:
"Stories are the single most powerful weapon in a leader's arsenal." -- Howard Gardner