Dr Sarkar stated, “Given the current job landscape, the methods of pursuing degrees and programs are evolving and getting digitised. Let’s take a look at a couple of examples, such as MTech Programs and MBA Programs. Classically, they are about depth in specific branches. Now, an MTech program or MBA program no longer includes only the core disciplines, rather, it has become a fusion of important disciplines required to solve real-time problems.” “Therefore, even if you are trying to think of yourself as going through the technology route, doing an MTech program, you will probably end up doing a fair amount of business applications using data, given the kinds of projects and courses. Similarly for an MBA program, you will go beyond the core disciplines and you will also use data and technology. The traditional programs are evolving to fit today’s workplace,”he added. At present, data holds a special place among organisations. This is one of the reasons why data is embedded within the current programs. The deployment of data is done through technology, for instance through cloud-based applications, he said.
First, when it comes to firmware updates, it is advisable to initiate an orchestrated process that ensures only authorized administrators can make changes to the device and that the update is applied properly. An update failure should trigger an alert so the device can be otherwise secured or replaced by another device. Second, for patients, cybersecurity leaders must give clear instructions on how to install and configure the device as well as the home network. This will translate into proper operation and a secure connection to transmit encrypted data from patient to doctor. One potential solution is to tailor the device connection type. For example, peer-to-peer connections bypass the public cloud to deliver encrypted information between user and device. Third, for devices, strong authentication with public key schemes is a must. Similar to what is used by online banks, public key authentication uses cryptographic keys to identify and authenticate peers instead of a username and password. Using cryptographic keys for authentication has the advantage that they are practically impossible to brute-force crack and do not require the user to remember anything.
The number one reason, from my experience, is the nature of our work being “high-risk”. Meaning, when we write the first line of code in the script, we usually don’t know what will happen with it — Will it work? Will it be in production? Will we use it ever again? Is it worth anything? We might end up spending much of our time on risky POCs or one-time data explorations. In those cases, writing the neatest time-consuming code might not be the right way to go. But then, this POC we wrote in a sketchy fashion turns into an actual project, it even gets to production, and its code is a mess! Sounds familiar? Used to happen to me all the time. ... What’s common to all code writers out there is the time aspect. Writing clean code costs more time in the first place since you need to think twice before writing any line of code. We’re always pushed or encouraged to get things done, fast, and it might come at the expense of our code. Just remember — getting things done fast, while in a hurry, can come to bite you later when you’re dealing with bugs on a daily basis. Your time spent writing clean code will for sure pay for itself in the time saved on bugs.
In the age of remote work, it's easier than ever to blur the lines between our personal and professional tech. Maybe it's sending personal texts or emails from your work phone, editing personal documents or photos on your work laptop, or joining a virtual happy hour with friends from your work tablet. None of these actions may sound like a particularly risky activity, but as a former "IT guy" I'm asking, nay pleading, with you to stop doing them. At least the potentially more hazardous activities, such as storing personal data on your work machine or storing sensitive company data on your personal devices. Do it for the security of your employer. But more importantly, do it for the safety, privacy and wellbeing of yourself, your family and friends. Cybersecurity incidents can have serious negative consequences for both your employer and you. And even if an actual security breach or data leak doesn't occur, you could be reprimanded, demoted, fired, sued or even criminally prosecuted. Take the case of former CIA director John M. Deutch.
Without a doubt, the cyber security teams in your business are finding themselves in an increasingly complex situation. The adoption of the cyber security mesh has been effectively accelerated by several drivers, including digital initiatives and the opportunity to take advantage of IoT, AI, advanced analytics and the cloud. These drivers, along with the demand for increased flexibility, reliability and agility, have led more and more businesses to adopt a cyber security mesh. This distributed cyber security approach offers a much-needed chance for increased reliability, flexibility and scalability. ... Ultimately, the continued breakdown of the traditional technology stack with elevated virtualisation of services means the way organisations look to protect themselves is set for an upgrade. Effective cyber security is about being able to match and marry your protection to the circumstances in the world around it. As a society, as technology and even government policy begins to change, so will your points of exposure. Of course, the past year has seen an acceleration in these changes, and this has demonstrated that businesses should be as prepared for the unlikely as they are for the likely, which is exactly what a robust cyber security plan should look like.
Doing test automation is about writing code. Test automation code can be easily treated as “second-class citizens”. As it’s not delivered to customers, development is often less formalized and may lack the scrutiny and quality practices otherwise applied in the organization. Lately, I’ve been doing lots of code reviews. ... All of the reviews exclusively cover end-to-end test automation: new tests, old fixes, config changes, and framework updates. I adamantly believe that test automation code should undergo the same scrutiny of review as the product code it tests because test automation is a product. Thus, all of the same best practices should be applied. Furthermore, I also look for problems that, anecdotally, seem to appear more frequently in test automation than in other software domains. Code review is a very important phenomenon in the SOFTWARE development process. Made popular by the open-source community, it is now the standard for any team of developers. If it is executed correctly, the benefit is not only in reducing the number of bugs and better code quality but also in the training effect for the programmer.
It’s common knowledge in the tech world that the vast majority of organizations shifting to public cloud are adopting a mix of hybrid and multi-cloud operating models as part of their cloud strategy. In response, all three of the major cloud providers, including Amazon, Microsoft, and Google, are expanding their service offerings for this positioning. Correspondingly, the market is seeing an uptick in customers that are using these hybrid and multi-cloud environments. According to a recent Gartner research statistic, over 80% of enterprises characterize their strategy as multi-cloud. This can run the gamut from organizations deploying a combination of providers to create a multi-cloud network to firms implementing five or more unique public cloud environments. In reality, while these organizations think they are operating in a multi-cloud environment, they are simply operating “multiple clouds.” This is more than just semantics: Multiple cloud does not equal multi-cloud. And not understanding the nuances may leave a lot on the table when it comes to a CIO managing enterprise IT.
Because developers work with code and in Git, it is logical to apply security controls in Git. Looking at secrets leaks, shifting left means automatically detecting secrets in the code and allowing the different members of the SDLC to collaborate. Remediating secrets leaked in Git repositories is a shared responsibility among developers, operations, and application security (if the secret is exposed in internal code repos) or threat response (if the secret is exposed externally). The processes depend on the organization's size, culture, and how it splits responsibilities among teams. They all need one another, but developers are on the front line. They often know what the leaked secret gives access to. However, they can't always revoke the secret alone because it might affect production systems or fellow developers using the same credentials. Also, it's not only about revoking; it's also about redistributing (rotating), which falls under operations' responsibilities. While remediating, it is also important to keep security professionals' eyes on the issue. They can guarantee that proper remediation steps are followed and guide and educate developers on the risks.
Porter says BP's initial implementations of Agile have helped the company to embed its working processes into various areas of the business. He says the benefits of an Agile way of working are clear. "'It's really liberating' is what we're hearing from the various pilots and work that has started already," he says. "So we're seeing that play out in the broader BP and getting some really good indications back from where we have used Agile in the past and what's coming at us as we embed our design throughout the organisation." The introduction of Agile leadership isn't without its challenges. As managers empower their teams, so they stop being involved in the minutiae of decision-making processes. Get Agile management wrong and there's the possibility for chaos and anarchy. Good Agile managers don't use command-and-control approaches to manage their staff, but they do focus on fostering accountability. Porter says BP wants to avoid diluting the devolved decision-making processes that Agile encourages. Teams at the company are typically organised into small groups of between 10 and 20 people, depending on the organisational context.
Your product backlog should be a list of all the product-related tasks your team needs to complete, including the division of responsibility and the time frame. The problem is that the list is not intended to be conclusive. It needs to be flexible and will change according to the other things that are happening. For example, a hotshot product release by a competitor may mean you need to release a product update earlier than expected to compete, meaning everything else gets pushed back. Even events such as attending conferences (virtual or in-person) may mean that teams may prioritize sales and marketing visible tasks in an effort to connect with new customers. But the problem occurs when tasks keep getting pushed below the list, and the product manager struggles to maintain momentum to review and organize all the tasks in preference and priority. An effective product backlog list needs to be well structured, organized to be easily read and understood, and arranged to meet the company's strategic needs.
Quote for the day:
"Strong leaders encourage you to do things for your own benefit, not just theirs." -- Tim Tebow